Open Stack

On 28 April 2015 at 05:52, Russell Bryant <rbryant at redhat.com> wrote:

> On 04/28/2015 06:25 AM, Rossella Sblendido wrote:
> >
> >
> > On 04/28/2015 03:24 AM, Armando M. wrote:
> >>     >> UnsupportedVersion error if the version is not bumped in their
> agent too.
> >>     >>
> >>     >
> >>     > Could the server fall back and keep on using the old version of
> the API? I
> >>     > think that would make for a much nicer experience, especially in
> face of
> >>     > upgrades. Is this not possible? If it is, then the in vs out
> matter is not
> >>     > really an issue and out-of-tree code can reflect the change in
> API at their
> >>     > own pace.
> >>
> >>     while it's indeed nicer, it's difficult as port_update is
> >>     an async call (cast) and does not wait for errors
> >>     including UnsupportedVersion.
> >>
> >>
> >> Then, let's figure out how to change it!
> >
> > Russell suggested a way to handle it using a version_cap. It doesn't
> > seem a trivial change and Russell already mentioned that it adds
> > complexity. If we feel that it's necessary I can look into it.
>
> Armando's suggestion is possible if the method is changed from cast() to
> call(), but switching from async to sync has a cost, too.
>
>
For the type of communication paradigm needed in this case, I don't think
that switching to call from cast is really a viable solution. Even though
this circumstance may as well be handled as suggested above (assumed that
the breakage is adequately advertised like via [1] and IRC meetings), I
think there might be a couple of things worth considering, if backward
compatibility as well as rolling upgrades are a must-meet requirement (and
I would like to think that they are):

a) introduce a new, enhanced, port_update topic to be used by more capable
agents: in this case the server could fanout to the two separate topics. We
could get rid of this logic in due course to go back to a simpler model
made by a single fanout.

b) have the server be aware of the agent's version (after all they all
report state, which could include their capabilities in the form of a list
of RPC API versions) and selectively cast requests based on their
capabilities.

Both a) and b) would introduce no operator complexity, at a price of more
elaborated RPC method implementation.

I realize that we can't roll upgrade today, but forklift upgrades are bad
and we should take a serious look at what practices we could put in place
to address this aspect once and for all.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage

> --
> 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/20150428/ddc4b3ee/attachment.html>