<div dir="ltr">To put in another way I think we might say that change 154670 broke backward compatibility on the RPC interface.<div><div>To be fair this probably happened because RPC interfaces were organised in a way such that this kind of breakage was unavoidable.<div><br></div><div>I think the strategy proposed by Assaf is a viable one. The point about being able to do rolling upgrades only from version N to N+1 is a sensible one, but it has more to do with general backward compability rules for RPC interfaces.</div></div></div><div><br></div><div>In the meanwhile this is breaking a typical upgrade scenario. If a fix allowing agent state updates both namespaced and not is available today or tomorrow, that's fine. Otherwise I'd revert just to be safe.</div><div><br></div><div>By the way, we were supposed to have already removed all server rpc callbacks in the appropriate package... did we forget out this one or is there a reason for which it's still in neutron.db?</div><div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 March 2015 at 17:23, Miguel Ángel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<span style="font-size:14px">I agree with Assaf, this is an issue across updates, and</span></div><div><span style="font-size:14px">we may want (if that’s technically possible) to provide </span></div><div><span style="font-size:14px">access to those functions with/without namespace.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Or otherwise think about reverting for now until we find a</span></div><div><span style="font-size:14px">migration strategy</span></div><div><span style="font-size:14px"><br></span></div><div><a href="https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/rpc-docs-and-namespaces,n,z" target="_blank">https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/rpc-docs-and-namespaces,n,z</a></div><div><br></div><div><br></div>
<div><div><span style="font-size:14px">Best regards,</span></div><div><span style="font-size:10pt">Miguel Ángel Ajo</span></div><div><br></div></div><div class="HOEnZb"><div class="h5">
<p style="color:#a0a0a8">On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div>Hello everyone,</div><div><br></div><div>I'd like to highlight an issue with:</div><div><a href="https://review.openstack.org/#/c/154670/" target="_blank">https://review.openstack.org/#/c/154670/</a></div><div><br></div><div>According to my understanding, most deployments upgrade the controllers first</div><div>and compute/network nodes later. During that time period, all agents will</div><div>fail to report state as they're sending the report_state message outside</div><div>of any namespace while the server is expecting that message in a namespace.</div><div>This is a show stopper as the Neutron server will think all of its agents are dead.</div><div><br></div><div>I think the obvious solution is to modify the Neutron server code so that</div><div>it accepts the report_state method both in and outside of the report_state</div><div>RPC namespace and chuck that code away in L (Assuming we support rolling upgrades</div><div>only from version N to N+1, which while is unfortunate, is the behavior I've</div><div>seen in multiple places in the code).</div><div><br></div><div>Finally, are there additional similar issues for other RPC methods placed in a namespace</div><div>this cycle?</div><div><br></div><div><br></div><div>Assaf Muller, Cloud Networking Engineer</div><div>Red Hat</div><div><br></div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><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></div></div></div></span>
</blockquote>
<div>
<br>
</div>
</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>
<br></blockquote></div><br></div>