[openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
armamig at gmail.com
Tue Apr 28 15:07:56 UTC 2015
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  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
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.
> Russell Bryant
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev