Gyorgy Szombathelyi <gyorgy.szombathe...@doclerholding.com> wrote:
Hi!
Maybe I'm overseeing something, but I'm wondering if table renames breaks
rolling upgrades.
Yes, they would. Do you suggest that we allowed such a migration anywhere
in Newton?
E.g. if I'm upgrading neutron server instances one-by-one, and doing a db
expand during the process,
the old neutron-server instances will continue to work. However, without
the new renamed tables, the
new instances won't work. Just would be good to know:
With the current approach to neutron-server upgrades that neutron team
supports, we don’t allow new neutron-servers running while contract phase
is not applied yet. The process is documented at:
http://docs.openstack.org/developer/neutron/devref/upgrade.html#server-upgrade
- In this form, why the expand phase is useful? The expanded database
won't work with a new server instance, and it is not required for the
older ones.
It contains operations that are safe to execute while old neutron-server
instances are running. After expansion happens, you must shutdown all
neutron-servers, then apply contract phase, then start your new
neutron-servers. This is the only scenario currently supported.
- Actually what would be the workflow for a downtime-less upgrade? From
Liberty to Mitaka it worked fairly good, even without
using expand-contract.
Depending on what you mean by asking for downtime-less. If it’s data plane
wise, current agents should be able to work and upgrade without disrupting
any data flows. If you suggest that neutron API should be available at all
times, then this scenario is just not supported at this moment.
While your mileage may vary, I really doubt you could safely upgrade L->M
without API downtime. You are either lucky, or you just haven’t noticed
some failures. The way we currently handle database access does not
accommodate for no-downtime upgrade process for api endpoints. We are
looking into implementing some form of it in Ocata, but only time will tell
if we succeed to deliver. Until then, you can’t avoid API downtime.
Ihar
__________________________________________________________________________
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
