Open Stack

Looks like most people thing that building backup/re-install approach is
more viable. So, we certainly need to invent completely new upgrade from
and thus my suggestion is disable building/testing upgrade tarball right
now, because anyway it makes no sense.


Vladimir Kozhukalov

On Fri, Nov 6, 2015 at 8:21 PM, Vladimir Kuklin <vkuklin at mirantis.com>
wrote:

> Just my 2 cents here - let's do docker backup and roll it up onto brand
> new Fuel 8 node.
>
> On Fri, Nov 6, 2015 at 7:54 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
> wrote:
>
>> Matt,
>>
>> You are talking about this part of Operations guide [1], or you mean
>> something else?
>>
>> If yes, then we still need to extract data from backup containers. I'd
>> prefer backup of DB in simple plain text file, since our DBs are not that
>> big.
>>
>> [1]
>> https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn <mmosesohn at mirantis.com>
>> wrote:
>>
>>> Oleg,
>>>
>>> All the volatile information, including a DB dump, are contained in the
>>> small Fuel Master backup. There should be no information lost unless there
>>> was manual customization done inside the containers (such as puppet
>>> manifest changes). There shouldn't be a need to back up the entire
>>> containers.
>>>
>>> The information we would lose would include the IP configuration
>>> interfaces besides the one used for the Fuel PXE network and any custom
>>> configuration done on the Fuel Master.
>>>
>>> I want #1 to work smoothly, but #2 should also be a safe route.
>>>
>>> On Fri, Nov 6, 2015 at 5:39 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
>>> wrote:
>>>
>>>> Evgeniy,
>>>>
>>>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L <eli at mirantis.com> wrote:
>>>>
>>>>> Also we should decide when to run containers
>>>>> upgrade + host upgrade? Before or after new CentOS is installed?
>>>>> Probably
>>>>> it should be done before we run backup, in order to get the latest
>>>>> scripts for
>>>>> backup/restore actions.
>>>>>
>>>>
>>>> We're working to determine if we need to backup/upgrade containers at
>>>> all. My expectation is that we should be OK with just backup of DB, IP
>>>> addresses settings from astute.yaml for the master node, and credentials
>>>> from configuration files for the services.
>>>>
>>>> --
>>>> Best regards,
>>>> Oleg Gelbukh
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
>>>>> vkozhukalov at mirantis.com> wrote:
>>>>>
>>>>>> Dear colleagues,
>>>>>>
>>>>>> At the moment I'm working on deprecating Fuel upgrade tarball.
>>>>>> Currently, it includes the following:
>>>>>>
>>>>>> * RPM repository (upstream + mos)
>>>>>> * DEB repository (mos)
>>>>>> * openstack.yaml
>>>>>> * version.yaml
>>>>>> * upgrade script itself (+ virtualenv)
>>>>>>
>>>>>> Apart from upgrading docker containers this upgrade script makes
>>>>>> copies of the RPM/DEB repositories and puts them on the master node naming
>>>>>> these repository directories depending on what is written in openstack.yaml
>>>>>> and version.yaml. My plan was something like:
>>>>>>
>>>>>> 1) deprecate version.yaml (move all fields from there to various
>>>>>> places)
>>>>>> 2) deliver openstack.yaml with fuel-openstack-metadata package
>>>>>> 3) do not put new repos on the master node (instead we should use
>>>>>> online repos or use fuel-createmirror to make local mirrors)
>>>>>> 4) deliver fuel-upgrade package (throw away upgrade virtualenv)
>>>>>>
>>>>>> Then UX was supposed to be roughly like:
>>>>>>
>>>>>> 1) configure /etc/yum.repos.d/nailgun.repo (add new RPM MOS repo)
>>>>>> 2) yum install fuel-upgrade
>>>>>> 3) /usr/bin/fuel-upgrade (script was going to become lighter, because
>>>>>> there should have not be parts coping RPM/DEB repos)
>>>>>>
>>>>>> However, it turned out that Fuel 8.0 is going to be run on Centos 7
>>>>>> and it is not enough to just do things which we usually did during
>>>>>> upgrades. Now there are two ways to upgrade:
>>>>>> 1) to use the official Centos upgrade script for upgrading from 6 to 7
>>>>>> 2) to backup the master node, then reinstall it from scratch and then
>>>>>> apply backup
>>>>>>
>>>>>> Upgrade team is trying to understand which way is more appropriate.
>>>>>> Regarding to my tarball related activities, I'd say that this package based
>>>>>> upgrade approach can be aligned with (1) (fuel-upgrade would use official
>>>>>> Centos upgrade script as a first step for upgrade), but it definitely can
>>>>>> not be aligned with (2), because it assumes reinstalling the master node
>>>>>> from scratch.
>>>>>>
>>>>>> Right now, I'm finishing the work around deprecating version.yaml and
>>>>>> my further steps would be to modify fuel-upgrade script so it does not copy
>>>>>> RPM/DEB repos, but those steps make little sense taking into account Centos
>>>>>> 7 feature.
>>>>>>
>>>>>> Colleagues, let's make a decision about how we are going to upgrade
>>>>>> the master node ASAP. Probably my tarball related work should be reduced to
>>>>>> just throwing tarball away.
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/0687be44/attachment.html>