<div dir="ltr">Hello, guy! I've just saw your thread and I have something to say about your topic.<div><br></div><div>> What management tools are there?</div><div><br></div><div>The old time pacemaker users of course will name crm shell first (crmsh package). It allows interacive configuration by enetering commands like this:</div>
<div><div><br></div><div>> crm configure primitive test1 ocf:pacemaker:Dummy</div><div>> crm configure primitive test2 ocf:pacemaker:Dummy</div><div>> crm configure primitive test3 ocf:pacemaker:Dummy</div><div>> crm configure colocatin test2_with_test1 100: test2 test1</div>
<div>> crm configure order test3_after_test2 200: test2 test3</div></div><div><br></div><div>> crm status</div><div><br></div><div>Or by using editor:</div><div><br></div><div>> crm configure edit</div><div><br></div>
<div>There is also crm status and other usefull stuff.</div><div><br></div><div>This days crm is not developed anymore and considered unsupported and depricated. Most distributions will not have it packaged at all.</div><div>
<br></div><div>The newer configuration tools is pcs (pcs package). It allows intercative configuration and status monitoring too.</div><div><br></div><div>> pcs resource create test1 ocf:pacemaker:Dummy<br></div><div>> pcs resource create test2 ocf:pacemaker:Dummy<br>
</div><div>> pcs resource create test3 ocf:pacemaker:Dummy<br></div><div>> pcs constraint colocation add test2 test1 100<br></div><div><br></div><div>> pcs status</div><div><br></div><div>But it lacks crm's interctive shell and very convinient editor featutres. Pcs should be included in all moders distributions.</div>
<div><br></div><div>There are also basic tools written in C that come together with pacemaker itself and any sane distribution should include them.</div><div><a href="https://github.com/ClusterLabs/pacemaker/tree/master/tools">https://github.com/ClusterLabs/pacemaker/tree/master/tools</a><br>
</div><div>Some of them can be very convinient even for intercative use.</div><div><br></div><div>Both pcs and crm are just python wrappers that call basic C tools as a backend or parse XML cib.</div><div><br></div><div>> What options do we have to generate and/or manage pacemaker configuration?</div>
<div><br></div><div>In most cases it boils down to either adding and removing configuration elements during the installation or the runtime or to importing of the precreated configuration. YOur scripts can use crm/pcs to create primitives and constraints one by one as would human do. Or you can describe the entire configuration and then just import it.</div>
<div><br></div><div>Of couse you can always write pcs/crm calls to a shell script and just run it. crm can even run batch chages in one transaction like this:<br></div><div><div><br></div><div>config.crm:</div><div><br></div>
<div>configure</div><div>property stonith-enabled=false</div><div>property no-quorum-policy=ignore</div><div>primitive test1 ocf:pacemaker:Dummy<br></div><div>primitive test2 ocf:pacemaker:Dummy</div><div>primitive test3 ocf:pacemaker:Dummy</div>
<div>colocation test2_with_test1 100: test2 test1<br></div><div>order test3_after_test2 200: test2 test3</div><div>commit<br></div></div><div><br></div><div>then crm -f config.crm use --force if needed</div><div><br></div>
<div>pcs has no single transaction update capabilities but you can use shell script and shadow/commit if you really want transaction</div><div><br></div><div>The other solution would be to import precreated XML file as a patch:</div>
<div><br></div><div><div><diff></div><div> <diff-added></div><div> <cib></div><div> <configuration></div><div> <resources></div><div> <primitive class="ocf" id="test1" provider="pacemaker" type="Dummy"/></div>
<div> <primitive class="ocf" id="test2" provider="pacemaker" type="Dummy"/></div><div> <primitive class="ocf" id="test3" provider="pacemaker" type="Dummy"/></div>
<div> </resources></div><div> <constraints></div><div> <rsc_colocation id="test2_with_test1" rsc="test2" score="100" with-rsc="test1"/></div>
<div> <rsc_order first="test2" id="test3_after_test2" score="200" then="test3"/></div><div> </constraints></div><div> </configuration></div><div>
</cib></div><div> </diff-added></div><div></diff></div><div><br></div><div>If we can somehow generate such a file it can be easily applied like this:</div><div>cibadmin --patch --xml-file=patch.xml</div>
</div><div><br></div><div>You can also use crm_diff to apply xml patches manually.</div><div><br></div><div>I think, that for TripleO if you want import precreated configuration XML is a way to go. You will not depend on any python wrappers like pcs and crm and will be able to create any possible configuration.</div>
<div>XML allows use of XSLT transformations if you are creative enough of can be just generated by template or written manually.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-20 0:03 GMT+04:00 Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Anything we can take out of here for our HA fixes? May be we want to participate in the thread?<br><br><div class="gmail_quote">
---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Howley, Tom</b> <span dir="ltr"><<a href="mailto:tom.howley@hp.com" target="_blank">tom.howley@hp.com</a>></span><br>
Date: Wed, Jun 18, 2014 at 1:31 PM<br>Subject: Re: [openstack-dev] [TripleO] pacemaker management tools<br>To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<br><br>Jan/Adam,<br>
<br>
Is cibadmin available in the different distros? This can be used to update the CIB based on XML description of full pacemaker config. I have used this on ubuntu in the past and found it more reliable than using crm commands for automated deployment/configuration of pacemaker clusters. It also has patch facility, which I haven't used.<br>
<br>
I wouldn't have assumed that the pacemaker config needed to be a static file baked into an image. If cibadmin is an option, the different elements requiring pacemaker control could supply their relevant XML snippets (based off config values supplied via heat) and a pacemaker/pacemaker-config element could apply those XML configs to the running cluster (with checks for resource naming clashes, etc.) Does that sound like a possible approach?<br>
<span><font color="#888888"><br>
Tom<br>
</font></span><div><div><br>
-----Original Message-----<br>
From: Jan Provaznik [mailto:<a href="mailto:jprovazn@redhat.com" target="_blank">jprovazn@redhat.com</a>]<br>
Sent: 13 June 2014 13:53<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [TripleO] pacemaker management tools<br>
<br>
On 06/12/2014 09:37 PM, Adam Gandelman wrote:<br>
> It's been a while since I've used these tools and I'm not 100% surprised<br>
> they've fragmented once again. :) That said, does pcs support creating<br>
> the CIB configuration in bulk from a file? I know that crm shell would<br>
> let you dump the entire cluster config and restore from file. Unless<br>
> the CIB format has differs now, couldn't we just create the entire thing<br>
> first and use a single pcs or crm command to import it to the cluster,<br>
> rather than building each resource command-by-command?<br>
><br>
<br>
That is an interesting idea. But I'm afraid that this can't be used in<br>
TripleO use-case. We would have to keep the whole cluster definition as<br>
a static file which would be included when building overcloud image.<br>
Keeping this static definition up-to-date sounds like a complex task.<br>
Also this would make impossible any customization based on used<br>
elements. For example if there are 2 elements which use pacemaker -<br>
neutron-l3-agent and ceilometer-agent-central, then I couldn't use them<br>
separately.<br>
<br>
Jan<br>
<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>
_______________________________________________<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><span class="HOEnZb"><font color="#888888"><br>
</font></span></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Mike Scherbakov<br>#mihgen<br><br>
</font></span></div>
</blockquote></div><br></div>