Open Stack

Hi all,

I've been researching the Neutron project as a part of work on Openstack
rolling upgrades, my primary assignments included testing if there is no VM
access downtime when performing upgrade.



Are you aware of any issues that are present in Liberty release of Neutron,
that may cause the VM access downtime and may stop ops to pick up newest
versions of code?



When talking about no VM access downtime during upgrade, the sensitive
operations are:

   1. ensure that even after neutron services is shutoff/uninstalled, the
   traffic can go into the VM
   2. take care on neutron services startup/installation that existing
   configuration is preserved (routing tables, forwarding entries and security
   rules)
   3. the underlying network technologies (OVS, linux bridges etc.) is
   working without distraction when upgrading neutron code: no dropping table
   flows or applying the traffic rules to drop the packages



To be compatible between different versions of service talking to each
other, the important areas are:

   1. RPC API versioning
   2. Objects exchanged between services via RPC
   3. Database schema (bp [2]) and data migration



I have researched the ML2 plugin with ovs agent, including the
neutron-ovs-agent, dhcp-server, l3-agent, neutron-server.

One of the VM access downtime during upgrade is addressed in [1], removing
the flows in ovs after neutron agent restarts.



Is Neutron ready to be upgradable with minimal downtime of services and no
VM access downtime?

Are there any guidelines on using the oslo versionobjects and its priority
in Liberty cycle?

Are there use-cases written down when talking about Neutron upgrades?



[1] https://bugs.launchpad.net/neutron/+bug/1383674

[2]
https://review.openstack.org/#/c/192937/3/specs/liberty/online-schema-migrations.rst



Regards,

Artur Korzeniewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150709/70e98aae/attachment.html>