<div dir="ltr"><div><div><div><div>Hi Fuelers,<br><br></div>1. Sometimes fuel has non reversible changes. Here are a couple of samples<br></div>A new version needs to change/adjust Pacemaker primitives. Such changes affect all controllers in cluster.<br></div>A old API can be deprecated or new API can be introduced. Until we all components configured to use new API, it's almost impossible to keep half of cluster with old API and half cluster with new API.<br><br></div>2. For computes, even if we stop services VM instances should work. I think it's possible to upgrade without downtime of VM instances. Though I am not sure if it's possible for CEPH nodes.<br><br><br><div><div><div> <br></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div>
<br><div class="gmail_quote">On Tue, Sep 9, 2014 at 9:35 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>please see below original email below from Dmitry. I've modified the subject to bring larger audience to the issue.</div><div><br></div><div>I'd like to split the issue into two parts:</div><div><ol><li>Maintenance mode for OpenStack controllers in HA mode (HA-ed Keystone, Glance, etc.)</li><li>Maintenance mode for OpenStack computes/storage nodes (no HA)</li></ol><div>For first category, we might not need to have maintenance mode at all. For example, if we apply patching/upgrade one by one node to 3-node HA cluster, 2 nodes will serve requests normally. Is that possible for our HA solutions in Fuel, TripleO, other frameworks?</div></div><div><br></div><div>For second category, can not we simply do "nova-manage service disable...", so scheduler will simply stop scheduling new workloads on particular host which we want to do maintenance on?</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 6:44 PM, Dmitry Pyzhov <span dir="ltr"><<a href="mailto:dpyzhov@mirantis.com" target="_blank">dpyzhov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>All,</div><div><br></div><div>I'm not sure if it deserves to be mentioned in our documentation, this seems to be a common practice. If an administrator wants to patch his environment, he should be prepared for a temporary downtime of OpenStack services. And he should plan to perform patching in advance: choose a time with minimal load and warn users about possible interruptions of service availability.</div>


<div><br></div><div>Our current implementation of patching does not protect from downtime during the patching procedure. HA deployments seems to be more or less stable. But it looks like it is possible to schedule an action on a compute node and get an error because of service restart. Deployments with one controller... well, you won’t be able to use your cluster until the patching is finished. There is no way to get rid of downtime here.</div>


<div><br></div><div>As I understand, we can get rid of possible issues with computes in HA. But it will require migration of instances and stopping of nova-compute service before patching. And it will make the overall patching procedure much longer. Do we want to investigate this process?</div>


</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</font></span></div></div></div>
<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></blockquote></div><br></div>