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
