[openstack-dev] [TripleO] pacemaker management tools

Jan Provaznik jprovazn at redhat.com
Thu Jun 12 09:24:09 UTC 2014


On 06/12/2014 12:17 AM, Gregory Haynes wrote:
>> The issue is that distributions supported in TripleO provide different
>> tools for managing Pacemaker. Ubuntu/Debian provides crmsh, Fedora/RHEL
>> provides pcs, OpenSuse provides both. I didn't find packages for all our
>> distros for any of the tools. Also if there is a third-party repo
>> providing packages for various distros, adding dependency on an
>> untrusted third-party repo might be a problem for some users.
>>
>> Although it's a little bit annoying, I think we will end up with
>> managing commands for both config tools, a resource creation sample:
>>
>> if $USE_PCS;then
>>     crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params
>> ip=192.168.122.120 cidr_netmask=32 op monitor interval=30s
>> else
>>     pcs resource create ClusterIP IPaddr2 ip=192.168.0.120 cidr_netmask=32
>> fi
>
> This seems like a reasonable solution if we can ensure that we have CI
> for both branches of the installation. This is a big issue with our
> current mariadb/percona installation and it sounds like were heading
> down the same path here.

With mariadb/percona it's slightly different as these are separate 
elements and each of them works on all distros. With mariadb I was 
waiting until galera server is merged into Fedora (which already is), so 
it's a good time now to make it default for Fedora setup (a patch for 
this will be submitted soon).

> If we can make USE_PCS directly dependent on the installed distro that
> would be sufficient (CI for each distro would take care of the different
> branches) but this gets a bit more complicated if you want to split crm
> and pcs out into different elements (like in mariadb vs percona)...
>

Yes, usage of pcs is directly dependent on distro. Pcs/crm wouldn't be 
splitted into separate elements, it's just about calling 2 different 
commands in an os-refresh-config script depending on distribution (so we 
are sure both are tested).

Jan



More information about the OpenStack-dev mailing list