On 27 April 2015 at 18:16, YAMAMOTO Takashi <yamam...@valinux.co.jp> wrote:
> > 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 > > fwiw, it's ofagent, not ryu plugin. > > >> 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! > > YAMAMOTO Takashi > > > > > 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 >
__________________________________________________________________________ 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
