Open Stack

On Thu, Apr 30, 2015 at 9:25 PM, Jastrzebski, Michal <
michal.jastrzebski at intel.com> wrote:

> Hello,
>
> After discussions, we've spotted possible gap in versioned objects:
> backporting of too-new versions in RPC.
> Nova does that by conductor, but not every service has something like
> that. I want to propose another approach:
>
> 1. Milestone pinning - we need to make single reference to versions of
> various objects - for example heat in version 15.1 will mean stack in
> version 1.1 and resource in version 1.5.
> 2. Compatibility mode - this will add flag to service
> --compatibility=15.1, that will mean that every outgoing RPC communication
> will be backported before sending to object versions bound to this
> milestone.
>
> With this 2 things landed we'll achieve rolling upgrade like that:
> 1. We have N nodes in version V
> 2. We take down 1 node and upgrade code to version V+1
> 3. Run code in ver V+1 with --compatibility=V
> 4. Repeat 2 and 3 until every node will have version V+1
> 5. Restart each service without compatibility flag
>
> This approach has one big disadvantage - 2 restarts required, but should
> solve problem of backporting of too-new versions.
> Any ideas? Alternatives?
>

AFAIK if nova gets a message that is too new, it just forwards it on (and a
newer server will handle it).

With that this *should* work, shouldn't it?
1. rolling upgrade of heat-engine
2. db sync
3. rolling upgrade of heat-api

-Angus


>
> Regards,
> Michał
>
> __________________________________________________________________________
> 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/20150504/d403d370/attachment.html>