Hello,
Here some more insights and questions:
We have in total 4 separate clouds who need the upgrade with each more than
100 compute nodes. We just use the basic services like nova, keystone,
neutron, glance and horizon. No Cinder, heat, trove etc. Our network setup
is flat provider network, which means we don't use the neutron router. All
in all the from the openstack service perspective a minimal setup.
One of our cloud is set up as HA with two management nodes (keystone, nova,
horizon, glance) behind a haproxy. It's not a big deal to have the same
setup implemented in all clouds if it's helpful for the upgrade
We don't think about upgrading from Centos 6 to 7. Instead build new Centos
7 compute nodes and move the VMs with live migration (is it a good idea?)
The database schemes changes between the openstack versions, what does it
affect? Let's say we set up a second management node wit Centos 7 and the
openstack Juno/Kilo services will it work against the Centos 6/Icehouse
compute nodes and the Icehouse DB schema?
Cheers,
Chris
-----Original Message-----
From: rdo-list-bounces(a)redhat.com [mailto:rdo-list-bounces@redhat.com] On
Behalf Of Ihar Hrachyshka
Sent: Monday, August 17, 2015 18:18
To: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] OpenStack upgrade Icehouse Centos 6 best practice
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/17/2015 12:54 PM, Chris wrote:
Hello,
We currently plan to upgrade our Openstack setup from Icehouse to Juno
or even Kilo. This also includes a version upgrade on the host based
OS from Centos 6.6 to 7.x
That's a huge shift for one step! I suggest you split the OS and Openstack
upgrades into separate phases to simplify the job. I also don't think
upstream supports upgrades that skip a release or two. It may work, but
that's not guaranteed.
I have some questions regarding the upgrade an hope to learn from your
experience.
First question is, is there a Openstack version compatibility
guaranteed within the different releases? The idea behind it to
upgrade the different services (compute nodes / management nodes) in
separate phases.
The usual assumption is that we support backwards compatibility for one
release, so you can stage your upgrades. Note that you should first upgrade
controller services, then agents/computes, not vice versa.
Second, is the live-migration with block-migrate feature compatible
between versions. One upgrade solution we currently playing with is to
move existing VMs with live-migration & block-migrate (no shared
storage) to fresh installed Centos 7 Kilo compute nodes.
Any best practice tips highly appreciated!
Cheers,
Chris
_______________________________________________ Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJV0cL/AAoJEC5aWaUY1u57QVcIAKXMIsN8b9g0OOHuBkxwGSjn
bsLIdoTQWh4nfsLTZ7vKJxG28qYrFNzBSdo6RpD3rbU3nPDtfDGxcUdaGtcKXd6S
7THEqhTRV2RhYlEGNlKNGoA/DnOf7cgqllliUAxOqEdnh5Lpif/PORNhusm1n9yv
Bz15KW3ZK9a68xXffnNtLlaQ+xt79Ha0irBsiQ3K61GxKrkAj05ANLFscK6N1JqK
o5gBkKkF80Yj3mmzcT+jIseLJvD/8IjFipiauyrR3WxCyZTOv3AzGukTOciEYu6i
zbB9O76Uhng+Gngoi1rBlZfqVgFXmQt8sw5JW8m78m2NamqdDPJ+jL3kDH77ZdY=
=vFGY
-----END PGP SIGNATURE-----
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com