Open Stack

Some pedant comments inline.

Salvatore

On 13 July 2015 at 23:29, Russell Bryant <rbryant at redhat.com> wrote:

> On 07/13/2015 05:08 PM, Kevin Benton wrote:
> > Thanks for the info. So the equivalent in neutron would be if we just
> > ensure backward compatible AMQP APIs, right?
>
> There's a few parts:
>
> 1) Backwards compatibility with changes to the oslo.messaging APIs using
> API versioning (what you're referring to, I think).  Neutron does this
> (though not tested in a mixed version mid-upgrade environment yet).
>
> 2) Compatibility of the data sent over those interfaces.  This is where
> oslo.versionedobjects comes in.  Breakage here is much easier to miss
> since it's not always obvious when you're modifying a data structure
> that's sent over the wire.  There has been a ton of work in Nova to
> version the data sent over the wire and have the ability for a service
> (nova-conductor in nova's case) to be able to convert objects back to a
> version that an older service can understand.  This is the most likely
> way Neutron will break rolling upgrades right now, especially since it's
> not tested.
>

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.
Neutron now completely lacks a layer between the front-end API endpoint and
the plugin, which then manages DB access.
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".

But this discussion is really out of scope for this thread, so I'll stop
here.


> 3) DB schema.  Depending on what services access the db directly and
> what the rolling upgrade strategy is, there may be some additional
> constraints on making sure the db schema is backwards copmatible, too.
>

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).


>
> --
> Russell Bryant
>
> > On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant <rbryant at redhat.com
> > <mailto:rbryant at redhat.com>> wrote:
> >
> >     On 07/13/2015 04:09 AM, Kevin Benton wrote:
> >     >>because you won't have to run Neutron agents on compute nodes
> anymore.
> >     >
> >     > How will upgrades work for OVN?
> >
> >     We haven't written anything down yet, but here's what I expect.
> >
> >     Right now we're still changing the db schema however is needed
> without
> >     messing with versioning.  As we get to "production ready", I expect
> >     we'll start being strict about only making backwards compatible ovsdb
> >     schema changes to make upgrades easier.
> >
> >     There are 2 central components - ovn-northd and ovsdb-server - that
> >     would be upgraded first, which I would expect to be done at the same
> >     time as upgrading your Neutron control plane.  As long as any ovsdb
> >     schema changes are backwards compatible, you could do
> rolling-upgrades
> >     of ovn-controller on compute or network nodes.
> >
> >     --
> >     Russell Bryant
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Russell Bryant
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150714/7a793f2b/attachment-0001.html>