Open Stack

On Thu, Jan 19, 2017 at 8:27 AM, Matt Riedemann
<mriedem at linux.vnet.ibm.com> wrote:
> Sylvain and I were talking about how he's going to work placement
> microversion requests into his filter scheduler patch [1]. He needs to make
> requests to the placement API with microversion 1.4 [2] or later for
> resource provider filtering on specific resource classes like VCPU and
> MEMORY_MB.
>
> The question was what happens if microversion 1.4 isn't available in the
> placement API, i.e. the nova-scheduler is running Ocata code now but the
> placement service is running Newton still.
>
> Our rolling upgrades doc [3] says:
>
> "It is safest to start nova-conductor first and nova-api last."
>
> But since placement is bundled with n-api that would cause issues since
> n-sch now depends on the n-api code.
>
> If you package the placement service separately from the nova-api service
> then this is probably not an issue. You can still roll out n-api last and
> restart it last (for control services), and just make sure that placement is
> upgraded before nova-scheduler (we need to be clear about that in [3]).
>
> But do we have any other issues if they are not packaged separately? Is it
> possible to install the new code, but still only restart the placement
> service before nova-api? I believe it is, but want to ask this out loud.
>

Forgive me as I haven't looked really in depth, but if the api and
placement api are both collocated in the same apache instance this is
not necessarily the simplest thing to achieve.  While, yes it could be
achieved it will require more manual intervention of custom upgrade
scripts. To me this is not a good idea. My personal preference (now
having dealt with multiple N->O nova related acrobatics) is that these
types of requirements not be made.  We've already run into these
assumptions for new installs as well specifically in this newer code.
Why can't we turn all the services on and they properly enter a wait
state until such conditions are satisfied?

Thanks,
-Alex

> I think we're probably OK here but I wanted to ask this out loud and make
> sure everyone is aware and can think about this as we're a week from feature
> freeze. We also need to look into devstack/grenade because I'm fairly
> certain that we upgrade n-sch *before* placement in a grenade run which will
> make any issues here very obvious in [1].
>
> [1] https://review.openstack.org/#/c/417961/
> [2]
> http://docs.openstack.org/developer/nova/placement.html#filter-resource-providers-having-requested-resource-capacity
> [3]
> http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __________________________________________________________________________
> 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