Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
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. -- Russell Bryant __ 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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
On 28 April 2015 at 05:52, Russell Bryant rbry...@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-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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
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. cheers, Rossella __ 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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
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. 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
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
On 04/27/2015 12:09 PM, Rossella Sblendido 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. 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. Yes, if a new parameter is added, the minor version should be bumped. IMO, it should just be done in Neutron and the backend repos will have to deal with it. Ideally there is CI in place that catches the API change and they will adapt quickly. That's just the reality of having the repos split up like this. The alternative is to implement a version_cap option in Neutron that lets an administrator set a max version of messages allowed to be sent. Nova has a set of options like this for use during live upgrades. The client side has to check to see if it's allowed to send the newest version and if not, it falls back to an older version it knows how to send. This adds complexity for both development and operations, so it'd be better to avoid it unless really necessary. -- Russell Bryant __ 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
