Bogdan brings up a good point. fuel-createmirror in its current state pulls down an Ubuntu container and uses apt utilities inside. I know it's being replaced, but it's one instance of an item that might be overlooked by this process.
On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > 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 >
__________________________________________________________________________ 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
