[openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

Artur Korzen korroot at gmail.com
Thu Jul 9 20:16:47 UTC 2015

Thanks Ihar comments!

> > Is Neutron ready to be upgradable with minimal downtime of services
> > and no VM access downtime?
> As the ovs bug you refer to above, no, at least not in reference
> implementation. That's for data plane.

My understanding is that after the ovs neutron agent will be patched with
[1], the upgrade from Kilo to Liberty on dataplane should be less painful
that juno to Kilo. At least the VM access should be without connectivity
IF in Liberty will be no breaking changes merged, the messages exchanged on
RPC channel should be compatible between releases, as well as RPC API
versions. Do you agree?

> As for other services, neutron-server online schema migration should
> help, and I hope to get it implemented in L (though there are some
> obstacles that may block us; we'll see).
> As for live data migration, neutron code base is not ready yet to
> reasonably require live data migration being implemented in all
> patches that need data moves in database. The very first obstacle for
> that is that there is no middleware layer between sqlalchemy and the
> rest of neutron that would allow us to hide migration details.
> Oslo.versionedobjects is such a middleware. See below.
> >
> > Are there any guidelines on using the oslo versionobjects and its
> > priority in Liberty cycle?
> It's not a common priority for L, but we've started on this road
> inside feature/qos branch that will hopefully get into master some
> time after L-2. If interested, see:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects?h=f
> eature/qos
> Once the feature branch is merged into master, I plan to start
> converting existing resources to objects. It may take time and will
> definitely span to M. Depending on progress in this regard, we'll see
> whether we will be able to consider live data migration. At the
> moment, I don't see it happening in M, at least not at the start of it.

Maybe we can define the priorities on what should be changed into OVO
first, to have good starting point for Liberty and M release upgrade
process. I'm willing to help, as well as there can be some other volunteers
to join.

If the OVO cannot be delivered fully in Liberty, we should take care that
no breaking changes will be merged in Liberty and take necessary steps to
mitigate any risk of incompatibility of upgrades in
Kilo->Liberty->M-release process.

> >
> > Are there use-cases written down when talking about Neutron
> > upgrades?
> One thing that is currently in review are partial upgrades. They are
> tested for nova (including nova-network) but not for neutron, so it's
> considered a nova-network/neutron parity issue.
> You should find most of relevant patches in:
> https://review.openstack.org/#/q/owner:%22Russell+Bryant%22+status:open,
> n,z
> Ihar

Artur Korzeniewski

 [1] https://bugs.launchpad.net/neutron/+bug/1383674
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150709/8bae5fd8/attachment.html>

More information about the OpenStack-dev mailing list