Open Stack

To put in another way I think we might say that change 154670 broke
backward compatibility on the RPC interface.
To be fair this probably happened because RPC interfaces were organised in
a way such that this kind of breakage was unavoidable.

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.

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.

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?

Salvatore

On 4 March 2015 at 17:23, Miguel Ángel Ajo <majopela at redhat.com> wrote:

>  I agree with Assaf, this is an issue across updates, and
> we may want (if that’s technically possible) to provide
> access to those functions with/without namespace.
>
> Or otherwise think about reverting for now until we find a
> migration strategy
>
>
> https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/rpc-docs-and-namespaces,n,z
>
>
> Best regards,
> Miguel Ángel Ajo
>
> On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote:
>
> Hello everyone,
>
> I'd like to highlight an issue with:
> https://review.openstack.org/#/c/154670/
>
> According to my understanding, most deployments upgrade the controllers
> first
> and compute/network nodes later. During that time period, all agents will
> fail to report state as they're sending the report_state message outside
> of any namespace while the server is expecting that message in a namespace.
> This is a show stopper as the Neutron server will think all of its agents
> are dead.
>
> I think the obvious solution is to modify the Neutron server code so that
> it accepts the report_state method both in and outside of the report_state
> RPC namespace and chuck that code away in L (Assuming we support rolling
> upgrades
> only from version N to N+1, which while is unfortunate, is the behavior
> I've
> seen in multiple places in the code).
>
> Finally, are there additional similar issues for other RPC methods placed
> in a namespace
> this cycle?
>
>
> Assaf Muller, Cloud Networking Engineer
> Red Hat
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150304/2a5f14e3/attachment.html>