<div dir="ltr"><div>Hi crew,<br><br></div><div>Please see my inline comments.<br></div><br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Everyone,<br>
<br>
I was reading the blueprints mentioned here and thought I'd take the opportunity to introduce myself and ask a few questions.<br>
For those that don't recognise my name, Pacemaker is my baby - so I take a keen interest helping people have a good experience with it :)<br>
<br>
A couple of items stood out to me (apologies if I repeat anything that is already well understood):<br>
<br>
* Operations with CIB utilizes almost 100% of CPU on the Controller<br>
<br>
 We introduced a new CIB algorithm in 1.1.12 which is O(2) faster/less resource hungry than prior versions.<br>
 I would be interested to hear your experiences with it if you are able to upgrade to that version.<br></blockquote><div> </div><div>Our team is aware of that. That's really nice improvement. Thank you very much for that. We've prepared all packages, though we have feature freeze. Pacemaker 1.1.12 will be added to next release.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Corosync shutdown process takes a lot of time<br>
<br>
 Corosync (and Pacemaker) can shut down incredibly quickly.<br>
 If corosync is taking a long time, it will be because it is waiting for pacemaker, and pacemaker is almost always waiting for for one of the clustered services to shut down.<br></blockquote><div><br></div><div>As part of improvement we have idea to split signalling layer (corosync) and resource management (pacemaker) layers by specifying<br><pre class="">service { <br>       name: pacemaker
       ver:  1
}
</pre>and create upstart script to set start ordering. That will allow us<br><br></div><div>1. Create some notifications in puppet for pacemaker<br></div><div>2. Restart and manage corosync and pacemaker independently<br></div><div>3. Use respawn in upstart to restart corosync or pacemaker<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Current Fuel Architecture is limited to Corosync 1.x and Pacemaker 1.x<br>
<br>
 Corosync 2 is really the way to go.<br>
 Is there something in particular that is holding you back?<br>
 Also, out of interest, are you using cman or the pacemaker plugin?<br></blockquote><div><br></div><div>We use almost standard corosync 1.x and pacemaker from CentOS 6.5 and Ubuntu 12.04. However, we've prepared corosync 2.x and pacemaker 1.1.12 packages. Also we have update puppet manifests on review. As was said above, we can't just add at the end of development cycle.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
*  Diff operations against Corosync CIB require to save data to file rather<br>
  than keep all data in memory<br>
<br>
 Can someone clarify this one for me?<br></blockquote><div> </div><div>That's our implementation for puppet. We can't just use shadow on distributed environment, so we run <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 Also, I notice that the corosync init script has been modified to set/unset maintenance-mode with cibadmin.<br>
 Any reason not to use crm_attribute instead?  You might find its a less fragile solution than a hard-coded diff.<br></blockquote><div> </div><div>Can you give a particular line where you see that?  <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Debug process of OCF scripts is not unified requires a lot of actions from<br>
 Cloud Operator<br>
<br>
 Two things to mention here... the first is crm_resource --force-(start|stop|check) which queries the cluster for the resource's definition but runs the command directly. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Combined with -V, this means that you get to see everything the agent is doing.<br></blockquote><div><br></div><div>We write many own OCF scripts. We just need to see how OCF script behaves. ocf_tester is not enough for our cases. I'll try if crm_resource -V --force-start is better.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 Also, pacemaker now supports the ability for agents to emit specially formatted error messages that are stored in the cib and can be shown back to users.<br>
 This can make things much less painful for admins. Look for PCMK_OCF_REASON_PREFIX in the upstream resource-agents project.<br></blockquote><div><br></div><div>Thank you for tip. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
* Openstack services are not managed by Pacemaker<br></blockquote><div><br></div><div>The general idea to have all openstack services under pacemaker control rather than having upstart and pacemaker. It will be very handy for operators to see the status of all services from one console. Also it will give us flexibility to have more complex service verification checks in monitor function.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 Oh?<br>
<br>
* Compute nodes aren't in Pacemaker cluster, hence, are lacking a viable<br>
 control plane for their's compute/nova services.<br>
<br>
 pacemaker-remoted might be of some interest here.<br>
 <a href="http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Remote/index.html" target="_blank">http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Remote/index.html</a><br>
<br>
<br>
* Creating and committing shadows not only adds constant pain with dependencies and unneeded complexity but also rewrites cluster attributes and even other changes if you mess up with ordering and it’s really hard to debug it.<br>
<br>
 Is this still an issue?  I'm reasonably sure this is specific to the way crmsh uses shadows.<br>
 Using the native tools it should be possible to commit only the delta, so any other changes that occur while you're updating the shadow would not be an issue, and existing attributes wouldn't be rewritten.<br></blockquote><div><br></div><div>We are on the way to replace pcs and crm with native tools in puppet service provider.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Restarting resources by Puppet’s pacemaker service provider restarts them even if they are running on other nodes and it sometimes impacts the cluster.<br>
<br>
 Not available yet, but upstream there is now a smart --restart option for crm_resource which can optionally take a --host parameter.<br>
 Sounds like it would be useful here.<br>
 <a href="http://blog.clusterlabs.org/blog/2014/feature-spotlight-smart-resource-restart-from-the-command-line/" target="_blank">http://blog.clusterlabs.org/blog/2014/feature-spotlight-smart-resource-restart-from-the-command-line/</a><br>
<br>
* An attempt to stop or restart corosync service brings down a lot of resources and probably will fail and bring down the entire deployment.<br>
<br>
 That sounds deeply worrying.  Details?<br></blockquote><div> </div><div>As said above we need to separate corosync and pacemaker services. That will allow us to restart corosync or modify its config without touching resource logic.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Controllers other the the first download configured cib an immediate start all cloned resources before they are configured so they have to be cleaned up later.<br>
<br>
 By this you mean clones are being started on nodes which do not have the software? Or before the ordering/colocation constraints have been configured?<br></blockquote><div><br></div><div>The problem is how cluster is usually deployed. By default, puppet applies changes to one node, then to another and so on. When environment has clones, once pacemaker is installed, it will get configuration and would try to start resources on node immediately even if puppet is not done with catalog run. We implemented asymmetric cluster to mitigate such behavior. Though, I believe that more straight solution is to implement more complex orchestration.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
<br>
> On 15 Nov 2014, at 10:31 am, Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>> wrote:<br>
><br>
> +1 for ha-pacemaker-improvements<br>
><br>
> --<br>
> Best regards,<br>
> Sergii Golovatiuk,<br>
> Skype #golserge<br>
> IRC #holser<br>
><br>
> On Fri, Nov 14, 2014 at 11:51 PM, Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>> wrote:<br>
> Good plan, but I really hate the name of this blueprint. I think we<br>
> should stop lumping different unrelated HA improvements into a single<br>
> blueprint with a generic name like that, especially when we already<br>
> had a blueprint with essentially the same name<br>
> (ha-pacemaker-improvements). There's nothing wrong with having 4<br>
> trivial but specific blueprints instead of one catch-all.<br>
><br>
> On Wed, Nov 12, 2014 at 4:10 AM, Aleksandr Didenko<br>
> <<a href="mailto:adidenko@mirantis.com">adidenko@mirantis.com</a>> wrote:<br>
> > HI,<br>
> ><br>
> > in order to make sure some critical Haproxy backends are running (like mysql<br>
> > or keystone) before proceeding with deployment, we use execs like [1] or<br>
> > [2].<br>
> ><br>
> > We're currently working on a minor improvements of those execs, but there is<br>
> > another approach - we can replace those execs with puppet resource providers<br>
> > and move all the iterations/loops/timeouts logic there. Also we should fail<br>
> > catalog compilation/run if those resource providers are not able to ensure<br>
> > needed Haproxy backends are up and running. Because there is no point to<br>
> > proceed with deployment if keystone is not running, for example.<br>
> ><br>
> > If no one objects, I can start implementing this for Fuel-6.1. We can<br>
> > address it as a part of pacemaker improvements BP [3] or create a new BP.<br>
> ><br>
> > [1]<br>
> > <a href="https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/manifests/cluster_ha.pp#L551-L572" target="_blank">https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/manifests/cluster_ha.pp#L551-L572</a><br>
> > [2]<br>
> > <a href="https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33" target="_blank">https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33</a><br>
> > [3] <a href="https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements" target="_blank">https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements</a><br>
> ><br>
> > Regards,<br>
> > Aleksandr Didenko<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>
> ><br>
><br>
><br>
><br>
> --<br>
> Dmitry Borodaenko<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>
> 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>
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></div></div></div></div>