<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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><br></div></div>