On 27 April 2015 at 09:09, Rossella Sblendido <rsblend...@suse.com> wrote:

> Hello all,
>
> I am working at the blueprint "Restructure the L2 agent" [1] .
> One of the work item of this blueprint is to modify the port_update
> message to include the attributes of the ports that were modified. This
> is implemented in this patch [2] .
>
> The client side of the RPC is in AgentNotifierApi , the server side is
> implemented in the L2 agent. A problem arises since now the vendor
> plugins are out of the tree. If they use a custom L2 agent (like for
> example the Ryu plugin) when the patch is merged they will get an
> 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.

Cheers,
Armando


>
> I am writing this email as heads up and also to ask a question. The
> port_update signature on the server side is like this:
>
> def port_update(self, context, **kwargs)
>
> kwargs is used, no specific parameter is specified. If a new key is
> added like in this case, the minor version of the RPC should be bumped
> anyway? I think so.
>
> cheers,
>
> Rossella
>
> [1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
> [2] https://review.openstack.org/#/c/155223
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to