<div dir="ltr">><span style="font-size:12.8000001907349px">because you won't have to run Neutron agents on compute nodes anymore.</span><div class="" style="font-size:12.8000001907349px"></div><div class="" style="font-size:12.8000001907349px"><br></div><div class="" style="font-size:12.8000001907349px">How will upgrades work for OVN?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 2:30 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/09/2015 10:11 AM, Ihar Hrachyshka wrote:<br>
> On 07/09/2015 09:01 AM, Artur Korzen wrote:<br>
>> Hi all,<br>
><br>
>> I've been researching the Neutron project as a part of work on<br>
>> Openstack rolling upgrades, my primary assignments included<br>
>> testing if there is no VM access downtime when performing<br>
>> upgrade.<br>
><br>
><br>
><br>
>> Are you aware of any issues that are present in Liberty release<br>
>> of Neutron, that may cause the VM access downtime and may stop<br>
>> ops to pick up newest versions of code?<br>
><br>
><br>
><br>
>> When talking about no VM access downtime during upgrade, the<br>
>> sensitive operations are:<br>
><br>
>> 1. ensure that even after neutron services is<br>
>> shutoff/uninstalled, the traffic can go into the VM 2. take care<br>
>> on neutron services startup/installation that existing<br>
>> configuration is preserved (routing tables, forwarding entries<br>
>> and security rules) 3. the underlying network technologies (OVS,<br>
>> linux bridges etc.) is working without distraction when upgrading<br>
>> neutron code: no dropping table flows or applying the traffic<br>
>> rules to drop the packages<br>
><br>
><br>
><br>
>> To be compatible between different versions of service talking<br>
>> to each other, the important areas are:<br>
><br>
>> 1. RPC API versioning 2. Objects exchanged between services via<br>
>> RPC 3. Database schema (bp [2]) and data migration<br>
><br>
><br>
><br>
>> I have researched the ML2 plugin with ovs agent, including the<br>
>> neutron-ovs-agent, dhcp-server, l3-agent, neutron-server.<br>
><br>
>> One of the VM access downtime during upgrade is addressed in [1],<br>
>>  removing the flows in ovs after neutron agent restarts.<br>
><br>
><br>
><br>
>> Is Neutron ready to be upgradable with minimal downtime of<br>
>> services and no VM access downtime?<br>
><br>
> As the ovs bug you refer to above, no, at least not in reference<br>
> implementation. That's for data plane.<br>
><br>
> As for other services, neutron-server online schema migration<br>
> should help, and I hope to get it implemented in L (though there<br>
> are some obstacles that may block us; we'll see).<br>
><br>
> As for live data migration, neutron code base is not ready yet to<br>
> reasonably require live data migration being implemented in all<br>
> patches that need data moves in database. The very first obstacle<br>
> for that is that there is no middleware layer between sqlalchemy<br>
> and the rest of neutron that would allow us to hide migration<br>
> details. Oslo.versionedobjects is such a middleware. See below.<br>
><br>
><br>
>> Are there any guidelines on using the oslo versionobjects and its<br>
>>  priority in Liberty cycle?<br>
><br>
> It's not a common priority for L, but we've started on this road<br>
> inside feature/qos branch that will hopefully get into master some<br>
> time after L-2. If interested, see:<br>
><br>
> <a href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects?h=f" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects?h=f</a><br>
><br>
><br>
eature/qos<br>
><br>
> Once the feature branch is merged into master, I plan to start<br>
> converting existing resources to objects. It may take time and<br>
> will definitely span to M. Depending on progress in this regard,<br>
> we'll see whether we will be able to consider live data migration.<br>
> At the moment, I don't see it happening in M, at least not at the<br>
> start of it.<br>
><br>
><br>
>> Are there use-cases written down when talking about Neutron<br>
>> upgrades?<br>
><br>
> One thing that is currently in review are partial upgrades. They<br>
> are tested for nova (including nova-network) but not for neutron,<br>
> so it's considered a nova-network/neutron parity issue.<br>
><br>
> You should find most of relevant patches in:<br>
><br>
> <a href="https://review.openstack.org/#/q/owner:%22Russell+Bryant%22+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/owner:%22Russell+Bryant%22+status:open</a>,<br>
><br>
><br>
n,z<br>
<br>
</div></div>Yes, there's a ton of work to make rolling upgrades as robust as what<br>
Nova has done.  There's significant limitations to what Neutron can do<br>
without breaking it, but hopefully the grenade job would help us catch<br>
things that would break it sooner.  At the moment those jobs have been<br>
blocked pending some re-work of how the partial upgrade jobs work.<br>
<br>
As of the last release (Kilo), rolling upgrades from Juno with Neutron<br>
worked when verified manually.  I'm hoping we'll have the same for<br>
Liberty, but I'm not sure if anyone has tried it out recently.<br>
<br>
All of the things discussed here sound like good things to work on.  I<br>
actually thought a group was going to work on versioned objects for<br>
Kilo, but that never materialized.<br>
<br>
I'll also plug a project I'm working on (OVN, part of the Open vSwitch<br>
project), which I also think simplifies this a good bit for Neutron,<br>
because you won't have to run Neutron agents on compute nodes anymore.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>