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
