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. On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov < 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> 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> >> 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> 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> >>>> 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> 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://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://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://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 >>> >>> >> >> __________________________________________________________________________ >> 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 >> >> > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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