Open Stack

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 <sgolovatiuk at mirantis.com
> wrote:

> Hi,
>
> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <mmosesohn at 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 <bdobrelia at 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-request at 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-request at 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-request at 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-request at 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 <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/503c1f7a/attachment-0001.html>