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
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 w
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-i
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, 201
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 back
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/o
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
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 up
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'
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 supp
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 cre
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
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 packa
13 matches
Mail list logo
