<div dir="ltr"><div>Sergii, Clint,</div><div>to rephrase what you are saying - there are might be situations when our OpenStack API will not be responding, as simply services would be down for upgrade.</div><div>Do we want to support it somehow? For example, if we know that Nova is going to be down, can we respond with HTTP 503 with appropriate Retry-After time in header?</div><div><br></div><div>The idea is not simply deny or hang requests from clients, but provide them "we are in maintenance mode, retry in X seconds"</div><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Turbo Hipster was added to </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">the gate</span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">great idea, I think we should use it in Fuel too</span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">> </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">You probably would want 'nova host-servers-migrate <host>'</span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">yeah for migrations - but as far as I understand, it doesn't help with disabling this host in scheduler - there is can be a chance that some workloads will be scheduled to the host.</span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 6:02 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Mike Scherbakov's message of 2014-09-09 00:35:09 -0700:<br>
<span class="">> Hi all,<br>
> please see below original email below from Dmitry. I've modified the<br>
> subject to bring larger audience to the issue.<br>
><br>
> I'd like to split the issue into two parts:<br>
><br>
</span>>    1. Maintenance mode for OpenStack controllers in HA mode (HA-ed<br>
>    Keystone, Glance, etc.)<br>
>    2. Maintenance mode for OpenStack computes/storage nodes (no HA)<br>
<span class="">><br>
> For first category, we might not need to have maintenance mode at all. For<br>
> example, if we apply patching/upgrade one by one node to 3-node HA cluster,<br>
> 2 nodes will serve requests normally. Is that possible for our HA solutions<br>
> in Fuel, TripleO, other frameworks?<br>
<br>
</span>You may have a broken cloud if you are pushing out an update that<br>
requires a new schema. Some services are better than others about<br>
handling old schemas, and can be upgraded before doing schema upgrades.<br>
But most of the time you have to do at least a brief downtime:<br>
<br>
 * turn off DB accessing services<br>
 * update code<br>
 * run db migration<br>
 * turn on DB accessing services<br>
<br>
It is for this very reason, I believe, that Turbo Hipster was added to<br>
the gate, so that deployers running against the upstream master branches<br>
can have a chance at performing these upgrades in a reasonable amount of<br>
time.<br>
<span class=""><br>
><br>
> For second category, can not we simply do "nova-manage service disable...",<br>
> so scheduler will simply stop scheduling new workloads on particular host<br>
> which we want to do maintenance on?<br>
><br>
<br>
</span>You probably would want 'nova host-servers-migrate <host>' at that<br>
point, assuming you have migration set up.<br>
<br>
<a href="http://docs.openstack.org/user-guide/content/novaclient_commands.html" target="_blank">http://docs.openstack.org/user-guide/content/novaclient_commands.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Aug 28, 2014 at 6:44 PM, Dmitry Pyzhov <<a href="mailto:dpyzhov@mirantis.com">dpyzhov@mirantis.com</a>> wrote:<br>
><br>
> > All,<br>
> ><br>
> > I'm not sure if it deserves to be mentioned in our documentation, this<br>
> > seems to be a common practice. If an administrator wants to patch his<br>
> > environment, he should be prepared for a temporary downtime of OpenStack<br>
> > services. And he should plan to perform patching in advance: choose a time<br>
> > with minimal load and warn users about possible interruptions of service<br>
> > availability.<br>
> ><br>
> > Our current implementation of patching does not protect from downtime<br>
> > during the patching procedure. HA deployments seems to be more or less<br>
> > stable. But it looks like it is possible to schedule an action on a compute<br>
> > node and get an error because of service restart. Deployments with one<br>
> > controller... well, you won’t be able to use your cluster until the<br>
> > patching is finished. There is no way to get rid of downtime here.<br>
> ><br>
> > As I understand, we can get rid of possible issues with computes in HA.<br>
> > But it will require migration of instances and stopping of nova-compute<br>
> > service before patching. And it will make the overall patching procedure<br>
> > much longer. Do we want to investigate this process?<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>