Open Stack

On Thu, Jan 19, 2017 at 2:29 PM, Alex Schultz <aschultz at redhat.com> wrote:
>
> What are these issues? My original message was to highlight one
> particular deployment type which is completely independent of how
> things get packaged in the traditional sense of the word
> (rpms/deb/tar.gz).  Perhaps it's getting lost in terminology, but
> packaging the software in one way and how it's run can be two separate
> issues.  So what I'd like to know is how is that impacted by whatever
> ordering is necessary, and if there's anyway way not to explicitly
> have special cases that need to be handled by the end user when
> applying updates.  It seems like we all want similar things. I would
> like not to have to do anything different from the install for
> upgrade. Why can't apply configs, restart all services?  Or can I?  I
> seem to be getting mixed messages...
>
>

Sorry for being unclear on the issue. As Jay pointed out, if
nova-scheduler is upgraded before the placement service, the
nova-scheduler service will continue to start and take requests. The
problem is if the filter scheduler code is requesting a microversion
in the placement API which isn't available yet, in particular this 1.4
microversion, then scheduling requests will fail which to the end user
means NoValidHost (the same as if we don't have any compute nodes yet,
or available).

So as Jay also pointed out, if placement and n-sch are upgraded and
restarted at the same time, the window for hitting this is minimal. If
deployment tooling is written to make sure to restart the placement
service *before* nova-scheduler, then there should be no window for
issues.

--

Thanks,

Matt