Open Stack

Hello, guy! I've just saw your thread and I have something to say about
your topic.

> What management tools are there?

The old time pacemaker users of course will name crm shell first (crmsh
package). It allows interacive configuration by enetering commands like
this:

> crm configure primitive test1 ocf:pacemaker:Dummy
> crm configure primitive test2 ocf:pacemaker:Dummy
> crm configure primitive test3 ocf:pacemaker:Dummy
> crm configure colocatin test2_with_test1 100: test2 test1
> crm configure order test3_after_test2 200: test2 test3

> crm status

Or by using editor:

> crm configure edit

There is also crm status and other usefull stuff.

This days crm is not developed anymore and considered unsupported and
depricated. Most distributions will not have it packaged at all.

The newer configuration tools is pcs (pcs package). It allows intercative
configuration and status monitoring too.

> pcs resource create test1 ocf:pacemaker:Dummy
> pcs resource create test2 ocf:pacemaker:Dummy
> pcs resource create test3 ocf:pacemaker:Dummy
> pcs constraint colocation add test2 test1 100

> pcs status

But it lacks crm's interctive shell and very convinient editor featutres.
Pcs should be included in all moders distributions.

There are also basic tools written in C that come together with pacemaker
itself and any sane distribution should include them.
https://github.com/ClusterLabs/pacemaker/tree/master/tools
Some of them can be very convinient even for intercative use.

Both pcs and crm are just python wrappers that call basic C tools as a
backend or parse XML cib.

> What options do we have to generate and/or manage pacemaker configuration?

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.

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:

config.crm:

configure
property stonith-enabled=false
property no-quorum-policy=ignore
primitive test1 ocf:pacemaker:Dummy
primitive test2 ocf:pacemaker:Dummy
primitive test3 ocf:pacemaker:Dummy
colocation test2_with_test1 100: test2 test1
order test3_after_test2 200: test2 test3
commit

then crm -f config.crm use --force if needed

pcs has no single transaction update capabilities but you can use shell
script and shadow/commit if you really want transaction

The other solution would be to import precreated XML file as a patch:

<diff>
  <diff-added>
    <cib>
      <configuration>
        <resources>
          <primitive class="ocf" id="test1" provider="pacemaker"
type="Dummy"/>
          <primitive class="ocf" id="test2" provider="pacemaker"
type="Dummy"/>
          <primitive class="ocf" id="test3" provider="pacemaker"
type="Dummy"/>
        </resources>
        <constraints>
          <rsc_colocation id="test2_with_test1" rsc="test2" score="100"
with-rsc="test1"/>
          <rsc_order first="test2" id="test3_after_test2" score="200"
then="test3"/>
        </constraints>
      </configuration>
    </cib>
  </diff-added>
</diff>

If we can somehow generate such a file it can be easily applied like this:
cibadmin --patch --xml-file=patch.xml

You can also use crm_diff to apply xml patches manually.

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.
XML allows use of XSLT transformations if you are creative enough of can be
just generated by template or written manually.



2014-06-20 0:03 GMT+04:00 Mike Scherbakov <mscherbakov at mirantis.com>:

> Anything we can take out of here for our HA fixes? May be we want to
> participate in the thread?
>
> ---------- Forwarded message ----------
> From: Howley, Tom <tom.howley at hp.com>
> Date: Wed, Jun 18, 2014 at 1:31 PM
> Subject: Re: [openstack-dev] [TripleO] pacemaker management tools
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
>
>
> Jan/Adam,
>
> 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.
>
> 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?
>
> Tom
>
> -----Original Message-----
> From: Jan Provaznik [mailto:jprovazn at redhat.com]
> Sent: 13 June 2014 13:53
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] pacemaker management tools
>
> On 06/12/2014 09:37 PM, Adam Gandelman wrote:
> > It's been a while since I've used these tools and I'm not 100% surprised
> > they've fragmented once again. :)  That said, does pcs support creating
> > the CIB configuration in bulk from a file? I know that crm shell would
> > let you dump the entire cluster config and restore from file.  Unless
> > the CIB format has differs now, couldn't we just create the entire thing
> > first and use a single pcs or crm command to import it to the cluster,
> > rather than building each resource command-by-command?
> >
>
> That is an interesting idea. But I'm afraid that this can't be used in
> TripleO use-case. We would have to keep the whole cluster definition as
> a static file which would be included when building overcloud image.
> Keeping this static definition up-to-date sounds like a complex task.
> Also this would make impossible any customization based on used
> elements. For example if there are 2 elements which use pacemaker -
> neutron-l3-agent and ceilometer-agent-central, then I couldn't use them
> separately.
>
> Jan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140620/8ede2272/attachment.html>