Open Stack

Evgeniy

I am not sure you addressed me, but, anyway, - yes, we will have a
situation with old containers on new host node. This will be identical to
old host node from database migration point of view.

On Tue, Nov 10, 2015 at 7:38 PM, Evgeniy L <eli at mirantis.com> wrote:

> Hi Vladimir,
>
> Just to make sure that we are on the same page. We'll have to use upgrade
> script anyway, since you will need to run database migration and register
> new releases.
>
> Thanks,
>
> On Monday, 9 November 2015, Vladimir Kozhukalov <vkozhukalov at mirantis.com>
> wrote:
>
>> 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
>>>
>>>
>>
> __________________________________________________________________________
> 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/20151110/43dd3a7b/attachment.html>