<div dir="ltr">Some pedant comments inline.<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 13 July 2015 at 23:29, 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"><span class="">On 07/13/2015 05:08 PM, Kevin Benton wrote:<br>
> Thanks for the info. So the equivalent in neutron would be if we just<br>
> ensure backward compatible AMQP APIs, right?<br>
<br>
</span>There's a few parts:<br>
<br>
1) Backwards compatibility with changes to the oslo.messaging APIs using<br>
API versioning (what you're referring to, I think). Neutron does this<br>
(though not tested in a mixed version mid-upgrade environment yet).<br>
<br>
2) Compatibility of the data sent over those interfaces. This is where<br>
oslo.versionedobjects comes in. Breakage here is much easier to miss<br>
since it's not always obvious when you're modifying a data structure<br>
that's sent over the wire. There has been a ton of work in Nova to<br>
version the data sent over the wire and have the ability for a service<br>
(nova-conductor in nova's case) to be able to convert objects back to a<br>
version that an older service can understand. This is the most likely<br>
way Neutron will break rolling upgrades right now, especially since it's<br>
not tested.<br></blockquote><div><br></div><div>It is worth noting that versioned objects are helpful in any circumstance where you have a versioned RPC API be it AMQP or REST or whatever.</div><div>Neutron now completely lacks a layer between the front-end API endpoint and the plugin, which then manages DB access.</div><div>The now pretty much defunct "perestroika" blueprint aimed to do this; These versioned objects would live in this layer, which older folks like me who studied software engineering in late '90s would call "Business logic layer".</div><div><br></div><div>But this discussion is really out of scope for this thread, so I'll stop here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
3) DB schema. Depending on what services access the db directly and<br>
what the rolling upgrade strategy is, there may be some additional<br>
constraints on making sure the db schema is backwards copmatible, too.<br></blockquote><div><br></div><div>I guess if one properly uses object persistency so that DB access can be entirely performed via API objects, then #2 should imply #3 (and possibly even hide backward incompatible DB schema changes).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Russell Bryant<br>
<span class=""><br>
> On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><br>
</span><span class="">> <mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
><br>
> On 07/13/2015 04:09 AM, Kevin Benton wrote:<br>
> >>because you won't have to run Neutron agents on compute nodes anymore.<br>
> ><br>
> > How will upgrades work for OVN?<br>
><br>
> We haven't written anything down yet, but here's what I expect.<br>
><br>
> Right now we're still changing the db schema however is needed without<br>
> messing with versioning. As we get to "production ready", I expect<br>
> we'll start being strict about only making backwards compatible ovsdb<br>
> schema changes to make upgrades easier.<br>
><br>
> There are 2 central components - ovn-northd and ovsdb-server - that<br>
> would be upgraded first, which I would expect to be done at the same<br>
> time as upgrading your Neutron control plane. As long as any ovsdb<br>
> schema changes are backwards compatible, you could do rolling-upgrades<br>
> of ovn-controller on compute or network nodes.<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<div class="HOEnZb"><div class="h5">> <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>
><br>
><br>
><br>
><br>
> --<br>
> Kevin Benton<br>
><br>
><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>
><br>
<br>
<br>
--<br>
Russell Bryant<br>
<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></div></div></div>