<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 April 2015 at 05:52, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 04/28/2015 06:25 AM, Rossella Sblendido wrote:<br>
><br>
><br>
> On 04/28/2015 03:24 AM, Armando M. wrote:<br>
>>     >> UnsupportedVersion error if the version is not bumped in their agent too.<br>
>>     >><br>
>>     ><br>
>>     > Could the server fall back and keep on using the old version of the API? I<br>
>>     > think that would make for a much nicer experience, especially in face of<br>
>>     > upgrades. Is this not possible? If it is, then the in vs out matter is not<br>
>>     > really an issue and out-of-tree code can reflect the change in API at their<br>
>>     > own pace.<br>
>><br>
>>     while it's indeed nicer, it's difficult as port_update is<br>
>>     an async call (cast) and does not wait for errors<br>
>>     including UnsupportedVersion.<br>
>><br>
>><br>
>> Then, let's figure out how to change it!<br>
><br>
> Russell suggested a way to handle it using a version_cap. It doesn't<br>
> seem a trivial change and Russell already mentioned that it adds<br>
> complexity. If we feel that it's necessary I can look into it.<br>
<br>
</span>Armando's suggestion is possible if the method is changed from cast() to<br>
call(), but switching from async to sync has a cost, too.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>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):</div><div><br></div><div>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.</div><div> </div><div>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.</div><div><br></div><div>Both a) and b) would introduce no operator complexity, at a price of more elaborated RPC method implementation.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Armando</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage" target="_blank">https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888">
--<br>
Russell Bryant<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>