On 23.11.2015 12:47, Aleksandr Maretskiy wrote: > Hi all, > > as you know, Rally runs inside docker on Fuel master node, so docker > removal (good improvement) is a problem for Rally users. > > To solve this, I'm planning to make native Rally installation on Fuel > master node that is running on CentOS 7, > and then make a step-by-step instruction how to make this installation. > > So I hope docker removal will not make issues for Rally users.
I believe the most backwards compatible scenario is to keep the docker installed while removing the fuel-* docker things back to the host OS. So nothing would prevent user from pulling and running whichever docker containers he wants to put on the Fuel master node. Makes sense? > > On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov > <vkozhuka...@mirantis.com <mailto:vkozhuka...@mirantis.com>> wrote: > > ETA: > > experimental ISO w/o docker: tonight > spec: tomorrow night > > > > Vladimir Kozhukalov > > On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova > <aurlap...@mirantis.com <mailto:aurlap...@mirantis.com>> wrote: > > @Vova, > thanks for bringing this up. > The new approach without docker containers on master node really > has many advantages. > > @Igor, > regarding your question, I would say that we have many > dependencies from containers in CI/CD systems and test's > codebase. The test alignment to the new implementation won't be > easy. In such things we should move forward step by step. > As you know the first step is a spec file, can you give us a > link to it? > > > Nastya. > > On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh > <ogelb...@mirantis.com <mailto:ogelb...@mirantis.com>> wrote: > > With CentOS7 we will have python2.7 at Fuel Admin node as a > default version, I believe. > > -- > Best regards, > Oleg Gelbukh, > Principal Engineer > Mirantis > > On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov > <tnurlygaya...@mirantis.com > <mailto:tnurlygaya...@mirantis.com>> wrote: > > Hi Andrey, > > As far as I remember from the last usage of fuel > master node, there was Centos + py26 installation. > Python 2.6 is old enough and sometimes it is hard to > launch some application on fuel node without docker > (image with py27/py3). Are you planning to provide > py27 at least or my note is outdated and I can > already use py27 from the box? > > We can install docker on master node anyway to run Rally > / Tempest or other test suites and scripts from master > node with Python 2.7 or something also. > > On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin > <akuri...@mirantis.com <mailto:akuri...@mirantis.com>> > wrote: > > Hi! > I'm not fuel developer, so opinion below is based on > user-view. > As far as I remember from the last usage of fuel > master node, there was Centos + py26 installation. > Python 2.6 is old enough and sometimes it is hard to > launch some application on fuel node without docker > (image with py27/py3). Are you planning to provide > py27 at least or my note is outdated and I can > already use py27 from the box? > > On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov > <vkozhuka...@mirantis.com > <mailto:vkozhuka...@mirantis.com>> wrote: > > Dear colleagues, > > As might remember, we introduced Docker > containers on the master node a while ago when > we implemented first version of Fuel upgrade > feature. The motivation behind was to make it > possible to rollback upgrade process if > something goes wrong. > > Now we are at the point where we can not use our > tarball based upgrade approach any more and > those patches that deprecate upgrade tarball has > been already merged. Although it is a matter of > a separate discussion, it seems that upgrade > process rather should be based on kind of backup > and restore procedure. We can backup Fuel data > on an external media, then we can install new > version of Fuel from scratch and then it is > assumed backed up Fuel data can be applied over > this new Fuel instance. The procedure itself is > under active development, but it is clear that > rollback in this case would be nothing more than > just restoring from the previously backed up data. > > As for Docker containers, still there are > potential advantages of using them on the Fuel > master node, but our current implementation of > the feature seems not mature enough to make us > benefit from the containerization. > > At the same time there are some disadvantages like > > * it is tricky to get logs and other > information (for example, rpm -qa) for a > service like shotgun which is run inside one > of containers. > * it is specific UX when you first need to run > dockerctl shell {container_name} and then > you are able to debug something. > * when building IBP image we mount directory > from the host file system into mcollective > container to make image build faster. > * there are config files and some other files > which should be shared among containers > which introduces unnecessary complexity to > the whole system. > * our current delivery approach assumes we > wrap into rpm/deb packages every single > piece of the Fuel system. Docker images are > not an exception. And as far as they depend > on other rpm packages we forced to build > docker-images rpm package using kind of > specific build flow. Besides this package is > quite big (300M). > * I'd like it to be possible to install Fuel > not from ISO but from RPM repo on any rpm > based distribution. But it is double work to > support both Docker based and package based > approach. > > Probably some of you can give other examples. > Anyway, the idea is to get rid of Docker > containers on the master node and switch to > plane package based approach that we used before. > > As far as there is nothing new here, we just > need to use our old site.pp (with minimal > modifications), it looks like it is possible to > implement this during 8.0 release cycle. If > there are no principal objections, please give > me a chance to do this ASAP (during 8.0), I know > it is a huge risk for the release, but still I > think I can do this. > > > > > Vladimir Kozhukalov > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for > usage questions) > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Andrey Kurilin. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage > questions) > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
