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 <majop...@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-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