Constructing rvalues from exported resources.

[Krist van Besien]

Hello,

I am using the Radez/Paxemaker modules, and this allows me to define a cluster like this:

   class {'pacemaker::corosync':
      cluster_name => $control_clu_name,
      cluster_members => $control_clu_members,
      require => [ Package['ccs'],
    }

I currently define the cluster name and members in two parameters. If I add a host to the cluster I just add it's name to the $control_clu_members parameter.
Is there a way however to do this automatically? Have every host that has this class declared on export something, and use this. Is there a way one can use exported resources to construct strings to be used as rvalues?

[jcbollinger]

Not any good ways.  In any case, that idea doesn't look like a good fit for the module in question.  A quick examination leads me to believe that it will set up the cluster only once (on each node that has the pacemaker::corrosync class).  The resources exported by a given node are not available for collection until after the node has checked in at least once, however, so even if you could collect information that they exported, most nodes would initially get have an incomplete list of cluster members.  And that would stick.  To use that module effectively, it looks like you need to be able to enumerate the cluster members in advance.


John

[Krist van Besien]

On Tuesday, January 28, 2014 10:11:58 PM UTC+1, jcbollinger wrote:

Not any good ways.  In any case, that idea doesn't look like a good fit for the module in question.  A quick examination leads me to believe that it will set up the cluster only once (on each node that has the pacemaker::corrosync class).  The resources exported by a given node are not available for collection until after the node has checked in at least once, however, so even if you could collect information that they exported, most nodes would initially get have an incomplete list of cluster members.  And that would stick.  To use that module effectively, it looks like you need to be able to enumerate the cluster members in advance.

What would be the correct way of doing this then?

Krist
 

[jcbollinger]

On Wednesday, January 29, 2014 12:59:16 AM UTC-6, Krist van Besien wrote:

On Tuesday, January 28, 2014 10:11:58 PM UTC+1, jcbollinger wrote:

[...]  To use that module effectively, it looks like you need to be able to enumerate the cluster members in advance.

What would be the correct way of doing this then?

I'm uncertain what you mean.  If "doing this" refers to enumerating the cluster members in advance, then that can only be something that you, as cluster planner, do yourself, outside the scope of Puppet (c.f. "in advance").

If you're asking how to communicate that data to Puppet, then whatever data service is available is probably fine.  Hiera would be great for this.  With an ENC such as Foreman, you can have the ENC pass the member list to Puppet as a top-scope variable or as a parameter of one or more classes.  In that case, you may need to create a wrapper class around whatever third-party module you want to use; its role would be to pass on the ENC-provided data as module class parameters.

If "doing this" is supposed to mean something more general, along the lines of "using Puppet to arrange my nodes into a cluster," then how best to approach that depends on a great many factors.  We have already touched on some of those: what clustering software you want to use (if any), and the extent to which cluster membership can or must be dynamic.  We can probably help you with devising manifests that will accomplish your objectives, but to do so we need more information.


John

[Henrik Lindberg]

You could try out dalen's puppet-db query module. It allows you to
query information from the puppet db and use the result in various
ways in your manifests.

regards
- henrik

[jcbollinger]

On Wednesday, January 29, 2014 10:41:37 AM UTC-6, Henrik Lindberg wrote:

You could try out dalen's puppet-db query module. It allows you to
query information from the puppet db and use the result in various
ways in your manifests.

That addresses the issue of extracting information about resources declared by other nodes (whether it qualifies as a "good" solution or not), but it doesn't solve the radez/pacemaker-specific problem of needing to know the cluster members in advance.


John

[Krist van Besien]

On Wednesday, January 29, 2014 3:41:43 PM UTC+1, jcbollinger wrote:

I'm uncertain what you mean.  If "doing this" refers to enumerating the cluster members in advance, then that can only be something that you, as cluster planner, do yourself, outside the scope of Puppet (c.f. "in advance").

If you're asking how to communicate that data to Puppet, then whatever data service is available is probably fine.  Hiera would be great for this.  With an ENC such as Foreman, you can have the ENC pass the member list to Puppet as a top-scope variable or as a parameter of one or more classes.  In that case, you may need to create a wrapper class around whatever third-party module you want to use; its role would be to pass on the ENC-provided data as module class parameters.

If "doing this" is supposed to mean something more general, along the lines of "using Puppet to arrange my nodes into a cluster," then how best to approach that depends on a great many factors.  We have already touched on some of those: what clustering software you want to use (if any), and the extent to which cluster membership can or must be dynamic.  We can probably help you with devising manifests that will accomplish your objectives, but to do so we need more information.

To give you an idea. I defined the wollowing class:

class sws::services::cluster (

  $control_clu_name        = $sws::params::control_clu_name,
  $control_clu_members     = $sws::params::control_clu_members,

) inherits sws::params {

    package { 'ccs' :
      ensure => installed,

    }

    class {'pacemaker::corosync':
      cluster_name    => $control_clu_name,
      cluster_members => $control_clu_members,
      require         => Package['ccs']
    }

}

(There's a lot more in there, but I cut out the not so relevant bits...)

Currently this works, if I just declare the control_clu_name and control_clu_members parameters in advance, and then add this class to the nodes I listed in control_clu_members via Foreman.

Now when I add another node to the cluster I need to do two things: Add the class to the node in Foreman, and add it's fqdn to the control_clu_members parameter. I was just wondering if there was a way to do this last thing automatically.

Krist




 

[jcbollinger]

Although I don't doubt that your class is applied successfully when used as you describe, I am less confident that it produces the results you expect.  Specifically, I recommend you confirm that when adding a node to an existing, running cluster, your approach causes the other nodes to be updated to know about the new one.  The module appeared geared to not do that, but I didn't analyze it deeply enough to be certain.

As Henrik suggested, it is possible for the catalog compiler to query puppetdb to glean information about nodes that have already been configured.  If in fact I am mistaken about pre-existing nodes not being updated, then an approach based on such queries could do what you want.  If I am not mistaken about that, however, then your approach is irretrievably broken -- in that case, with the module you are currently using, you would need to tell Foreman what all the cluster nodes are going to be before you configure the first one.


John