Re: [openstack-dev] [Fuel] Master node upgrade

[Oleg Gelbukh]

We are going to address the problem using the following approach:

1. Backup settings from the Fuel 7.0 Master node, including configuration
files for bootstrap script, data from state database, security keys and
certs, etc
2. Restore settings on top of freshly installed Fuel 8.0 Master.
3. Upload database dump into the DB of Fuel 8.0 Master.
3. Perform required actions to apply migrations to Fuel state DB.

In this case, rollback scenario is either revert to Fuel 7.0 Master (if it
wasn't reinstalled), or apply the same procedure to fresh Fuel 7.0 Master
installation.

This scenario introduces different upgrade workflow vs what upgrade tarball
used. We will update user documentation with the new workload. Operators
will have to consider changes to their processes in accordance with the new
workflow.

I will update this list once we have some progress on this task. You can
also track it in the following blueprint:

https://blueprints.launchpad.net/fuel/+spec/upgrade-master-node-centos7

--
Best regards,
Oleg Gelbukh

On Tue, Nov 10, 2015 at 8:52 AM, Vladimir Kuklin 
wrote:

> 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  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 
>> 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 
>>> 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 
 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 <
> mmoses...@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 
>> wrote:
>>
>>> Evgeniy,
>>>
>>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
 vkozhuka...@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 

Re: [openstack-dev] [Fuel] Master node upgrade

[Vladimir Kuklin]

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  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 
> 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 
>> 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 
>>> 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 <
 mmoses...@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 
> wrote:
>
>> Evgeniy,
>>
>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
>>> vkozhuka...@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 

Re: [openstack-dev] [Fuel] Master node upgrade

[Evgeniy L]

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 
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  > 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 > > 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 >> > 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 > wrote:

> Evgeniy,
>
> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  > 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 <
>> vkozhuka...@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

Re: [openstack-dev] [Fuel] Master node upgrade

[Vladimir Kozhukalov]

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 
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 
> 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 
>> 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 
>>> wrote:
>>>
 Evgeniy,

 On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
> vkozhuka...@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.
>>

Re: [openstack-dev] [Fuel] Master node upgrade

[Evgeniy L]

Hi Vladimir,

Cannot say anything about 1st option, which is to use official Centos
scripts,
because I'm not familiar with the procedure, but since our installation is
not
really Centos, I have doubts that it's going to work correctly.

2nd option looks less risky. 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.

Thanks,

On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
vkozhuka...@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-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

Re: [openstack-dev] [Fuel] Master node upgrade

[Vladimir Kuklin]

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  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 
> 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 
>> wrote:
>>
>>> Evgeniy,
>>>
>>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
 vkozhuka...@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-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [Fuel] Master node upgrade

[Oleg Gelbukh]

Hi

We should think about separating packages for master node and openstack. I
> guess we should use 2 repository:
> 1. MOS - repository for OpenStack related nodes
> 2. MasterNode - repository for packages that are used for master node only.
>
>
At the moment, this is pretty simple as we only support Ubuntu as target
node system as of 7.0 and 8.0, and our Master node runs on CentOS. Thus,
our CentOS repo is for Fuel node, and Ubuntu repo is for OpenStack.


> 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
>>
>
> +1 for 2. We cannot guarantee that #1 will work smoothly. Also, there is
> some technical dept we cannot solve with #1 (i.e. - Docker device mapper).
> Also, the customer might have environments running on CentOS 6 so
> supporting all scenarios is quite hard. IF we do this we can redesign
> docker related part so we'll have huge profit later on.
>
>
In Upgrade team, we researched these 2 options. Option #1 allows us to keep
procedure close to what we had in previous versions, but it won't be
automatic as there are too many changes in our flavor of CentOS 6.6. Option
#2, on the other hand, will require developing essentially a new workflow:
1. backup the DB and settings,
2. prepare custom config for bootstrap_master_node script (to retain IP
addressing),
3. reinstall Fuel node with 8.0,
4. upload and upgrade DB,
5. restore keystone/db credentials

This sequence of steps is high level, of course, and might change in the
development. Its additional value that backup/restore parts of it could be
used separately to create backups of the Fuel node.

Our current plan is to pursue option #2 in the following 3 weeks. I will
keep this list updated on our progress as soon as we have any.

--
Best regards,
Oleg Gelbukh


> A a company we will help the clients who might want to upgrade from
> 5.1-7.0 to 8.0, but that will include analysing environment/plugins and
> making personal scenario for upgrade. It might be 'fuel-octane' to migrate
> workload to a new cloud or some script/documentation to perform upgrade.
>
>
>>
>> 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.
>>
>
> +1.
>
>
>> 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.
>>
>
> +2. That will allow us to:
> 1. Reduce ISO size
> 2. Increase ISO compilation by including -j8
> 3. Speed up CI
>
>
>>
>> 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
>>
>>
>
> __
> 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

Re: [openstack-dev] [Fuel] Master node upgrade

[Oleg Gelbukh]

Evgeniy,

On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
> vkozhuka...@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-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

Re: [openstack-dev] [Fuel] Master node upgrade

[Oleg Gelbukh]

On Fri, Nov 6, 2015 at 3:32 PM, Alexander Kostrikov  wrote:

> Hi, Vladimir!
> I think that option (2) 'to backup the master node, then reinstall it
> from scratch and then apply backup' is a better way for upgrade.
> In that way we are concentrating on two problems in one feature:
> backups and upgrades.
>
That will ease development, testing and also reduce feature creep.
>

Alexander, +1 on this.

--
Best regards,
Oleg Gelbukh

>
> P.S.
> It is hard to refer to (2) because You have thee (2)-s.
>
> On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
> vkozhuka...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Kind Regards,
>
> Alexandr Kostrikov,
>
> Mirantis, Inc.
>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>
>
> Tel.: +7 (495) 640-49-04
> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>
> Skype: akostrikov_mirantis
>
> E-mail: akostri...@mirantis.com 
>
> *www.mirantis.com *
> *www.mirantis.ru *
>
> __
> 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

Re: [openstack-dev] [Fuel] Master node upgrade

[Matthew Mosesohn]

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  wrote:

> Evgeniy,
>
> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
>> vkozhuka...@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-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
>
>
__
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

Re: [openstack-dev] [Fuel] Master node upgrade

[Oleg Gelbukh]

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 
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 
> wrote:
>
>> Evgeniy,
>>
>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L  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 <
>>> vkozhuka...@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-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
>>> 

Re: [openstack-dev] [Fuel] Master node upgrade

[Alexander Kostrikov]

Hi, Vladimir!
I think that option (2) 'to backup the master node, then reinstall it from
scratch and then apply backup' is a better way for upgrade.
In that way we are concentrating on two problems in one feature:
backups and upgrades.
That will ease development, testing and also reduce feature creep.

P.S.
It is hard to refer to (2) because You have thee (2)-s.

On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
vkozhuka...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Kind Regards,

Alexandr Kostrikov,

Mirantis, Inc.

35b/3, Vorontsovskaya St., 109147, Moscow, Russia


Tel.: +7 (495) 640-49-04
Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>

Skype: akostrikov_mirantis

E-mail: akostri...@mirantis.com 

*www.mirantis.com *
*www.mirantis.ru *
__
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

Re: [openstack-dev] [Fuel] Master node upgrade

[Sergii Golovatiuk]

Hi,

On Fri, Nov 6, 2015 at 11:29 AM, Vladimir Kozhukalov <
vkozhuka...@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)
>

We should think about separating packages for master node and openstack. I
guess we should use 2 repository:
1. MOS - repository for OpenStack related nodes
2. MasterNode - repository for packages that are used for master node only.

#2 is very important as it will allow to speed up the package delivery to
end user. User will see the exact packages for master node and
controllers/compute. Also, master node development can be boosted also as
we might reconfigure jobs to install and test package on master node
without spinning up OpenStack environment. That will save hours for our CI.

Concerning 'upstream' it should be done in the same way we do for Ubuntu.
Master node shouldn't redistribute CentOS packages. The customer should
decide which mirror to use. The customer might want to use official CentOS
7 mirror or own copy on own facilities.

* 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
>

+1 for 2. We cannot guarantee that #1 will work smoothly. Also, there is
some technical dept we cannot solve with #1 (i.e. - Docker device mapper).
Also, the customer might have environments running on CentOS 6 so
supporting all scenarios is quite hard. IF we do this we can redesign
docker related part so we'll have huge profit later on.

A a company we will help the clients who might want to upgrade from 5.1-7.0
to 8.0, but that will include analysing environment/plugins and making
personal scenario for upgrade. It might be 'fuel-octane' to migrate
workload to a new cloud or some script/documentation to perform upgrade.


>
> 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.
>

+1.


> 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.
>

+2. That will allow us to:
1. Reduce ISO size
2. Increase ISO compilation by including -j8
3. Speed up CI


>
> 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
>
>
__
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