Hey guys, Despite the fact I like containers (as deployment unit), we don't use them so. That means I +1 idea to drop containers, just because I believe that would
* simplify a lot of things * helps get rid of huge amount of hacks * increase master node deployment * release us from annoying support of upgrades / rollbacks that proved to be non-working well But I'd like to hear from QA how do we rely on container-based infrastructure? Would it be hard to change our sys-tests in short time? Thanks, Igor On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Folks > > I guess it should be pretty simple to roll back - install older version and > restore the backup with preservation of /var/log directory. > > On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk > <sgolovat...@mirantis.com> wrote: >> >> Hi, >> >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <mmoses...@mirantis.com> >> wrote: >>> >>> Vladimir, >>> >>> The old site.pp is long out of date and should just be recreated from the >>> content of all the other $service-only.pp files. >>> >>> My main question is how do we propose to do a rollback from an update (in >>> theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent >>> data directories (or symlink them?) to >>> /var/lib/fuel/$fuel_version/$service_name, as we are doing behind the scenes >>> currently with Docker? If we keep that mechanism in place, all the existing >>> puppet modules can be used without any modifications. On the same note, >>> upgrade/rollback is the same as backup and restore, that means our restore >>> should follow a similar approach. >>> -Matthew >> >> >> There only one idea I have is to do dual partitioning system. The similar >> approach is implemented in CoreOS. >> >>> >>> >>> On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya <bdobre...@mirantis.com> >>> wrote: >>>> >>>> On 19.11.2015 15:59, Vladimir Kozhukalov 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. >>>> >>>> A side-by-side upgrade, correct? That should work as well. >>>> >>>> > 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. >>>> >>>> There is another point, the containers long build time when installing >>>> the master node. >>>> >>>> > >>>> > 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, >>>> 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 >>> >> >> >> __________________________________________________________________________ >> 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 >> > > > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com > www.mirantis.ru > vkuk...@mirantis.com > > __________________________________________________________________________ > 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