<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><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></div><div>2) I think you misunderstand what is the difference between upstart/systemd and Pacemaker in this case. There are many cases when you need to have syncrhonized view of the cluster. Otherwise you will hit split-brain situations and have your cluster misfunctioning. Until OpenStack provides us with such means there is no other way than using Pacemaker/Zookeper/etc.</div></div></blockquote><div> </div><div>Could you please give some examples of those 'many cases' for openstack specifically?</div><div>As for my 'misunderstanding' - openstack services only need to be always up, not more than that. </div><div>Upstart does a perfect job there.</div><div><br></div><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><br></div><div>3) Regarding Neutron agents - we discussed it many times - you need to be able to control and clean up stuff after some service crashed. Currently, Neutron does not provide reliable ways to do it. If your agent dies and does not clean up ip addresses from the network namespace you will get into the situation of ARP duplication which will be a kind of split brain described in item #2. I personally as a system architect and administrator do not believe for this to change in at least several years for OpenStack so we will be using Pacemaker for a very long period of time.</div></div></blockquote><div><br></div><div>This has been changed already, and a while ago. </div><div>OCF infrastructure around neutron agents has never helped neutron in any meaningful way and is just an artifact from the dark past. </div><div>The reasons are: pacemaker/ocf doesn't have enough intelligence to know when to engage, as a result, any cleanup could only be achieved through manual operations. I don't need to remind you how many bugs were in ocf scripts which brought whole clusters down after those manual operations.</div><div>So it's just a way better to go with simple standard tools with fine-grain control.</div><div>Same applies to any other openstack service (again, not rabbitmq/galera)</div><div><br></div><div>> so we will be using Pacemaker for a very long period of time.<br></div><div>Not for neutron, sorry. As soon as we finish the last bit of such cleanup, which is targeted for 8.0</div><div><br></div><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>Now, back to the topic - we may decide to use some more sophisticated integral node health attribute which can be used with Pacemaker as well as to put node into some kind of maintenance mode. We can leverage User Maintenance Mode feature here or just simply stop particular services and disable particular haproxy backends. </div></div></blockquote><div><br></div><div>I think this kind of attribute, although being analyzed by pacemaker/ocf, doesn't need any new OS service to be put under pacemaker control.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div> </div><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 class="gmail_extra"><div><div><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 11:57 PM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@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 class="gmail_extra"><div class="gmail_quote"><span><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 class="gmail_extra"><div class="gmail_quote"><span><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"><span><br></span></blockquote><div><br></div></span><div>Mirantis does control neither Rabbitmq or Galera. Mirantis cannot assure their quality as well.</div></div></div></div></blockquote><div> </div></span><div>Correct, and rabbitmq was always the pain in the back, preventing any <b>real </b>enterprise usage of openstack where reliability does matter.</div><span><div><br></div><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 class="gmail_extra"><div class="gmail_quote"><span><div><br></div><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"><span>
> 2) it has terrible UX<br></span></blockquote><div><br></div></span><div>It looks like personal opinion. I'd like to see surveys or operators feedbacks. Also, this statement is not constructive as it doesn't have alternative solutions.</div></div></div></div></blockquote><div> </div></span><div>The solution is to get rid of terrible UX wherever possible (i'm not saying it is always possible, of course)</div><div>upstart is just so much better.</div><div>And yes, this is my personal opinion and is a summary of escalation team's experience.</div><span><div><br></div><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 class="gmail_extra"><div class="gmail_quote"><span><div> </div><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"><span>
> 3) it is not reliable<br></span></blockquote><div> </div></span><div>I would say openstack services are not HA reliable. So OCF scripts are reaction of operators on these problems. Many of them have child-ish issues from release to release. Operators made OCF scripts to fix these problems. A lot of openstack are stateful, so they require some kind of stickiness or synchronization. Openstack services doesn't have simple health-check functionality so it's hard to say it's running well or not. Sighup is still a problem for many of openstack services. Etc/etc So, let's be constructive here.</div></div></div></div></blockquote><div> </div></span><div>Well, I prefer to be responsible for what I know and maintain. Thus, I state that neutron doesn't need to be managed by pacemaker, neither server, nor all kinds of agents, and that's the path that neutron team will be taking.</div><div><br></div><div>Thanks,</div><div>Eugene. </div><div><div><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 class="gmail_extra"><div class="gmail_quote"><div><div><div></div><div> </div><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"><span>
><br>
<br>
</span>I disagree with #1 as I do not agree that should be a criteria for an<br>
open-source project.  Considering pacemaker is at the core of our<br>
controller setup, I would argue that if these are in fact true we need<br>
to be using something else.  I would agree that it is a terrible UX<br>
but all the clustering software I've used fall in this category.  I'd<br>
like more information on how it is not reliable. Do we have numbers to<br>
backup these claims?<br>
<span><br>
> (3) is not evaluation of the project itself, but just a logical consequence<br>
> of (1) and (2).<br>
> As a part of escalation team I can say that it has cost our team thousands<br>
> of man hours of head-scratching, staring at pacemaker logs which value are<br>
> usually slightly below zero.<br>
><br>
> Most of openstack services (in fact, ALL api servers) are stateless, they<br>
> don't require any cluster management (also, they don't need to be moved in<br>
> case of lack of space).<br>
> Statefull services like neutron agents have their states being a function of<br>
> db state and are able to syncronize it with the server without external<br>
> "help".<br>
><br>
<br>
</span>So it's not an issue with moving services so much as being able to<br>
stop the services when a condition is met. Have we tested all OS<br>
services to ensure they do function 100% when out of disk space?  I<br>
would assume that glance might have issues with image uploads if there<br>
is no space to handle a request.<br>
<span><br>
> So now usage of pacemaker can be only justified for cases where service's<br>
> clustering mechanism requires active monitoring (rabbitmq, galera)<br>
> But even there, examples when we are better off without pacemaker are all<br>
> around.<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
<br>
</span>After I sent this email, I had further discussions around the issues<br>
that I'm facing and it may not be completely related to disk space. I<br>
think we might be relying on the expectation that the local rabbitmq<br>
is always available but I need to look into that. Either way, I<br>
believe we still should continue to discuss this issue as we are<br>
managing services in multiple ways on a single host. Additionally I do<br>
not believe that we really perform quality health checks on our<br>
services.<br>
<br>
Thanks,<br>
-Alex<br>
<div><div><br>
<br>
><br>
> On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko <<a href="mailto:svasilenko@mirantis.com" target="_blank">svasilenko@mirantis.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov<br>
>> <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
>>><br>
>>> No pacemaker for os services, please.<br>
>>> We'll be moving out neutron agents from pacemaker control in 8.0, other<br>
>>> os services don't need it too.<br>
>><br>
>><br>
>> could you please provide your arguments.<br>
>><br>
>><br>
>> /sv<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div>-- <br><div><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>