Hi Jeff,

That sounds great! If I could set and get in puppet manifests as well as from a face that would be killer. Would this be in stdlib as a function or more deeply embedded into the DSL? I'm assuming I can further filter a list of hosts based on facter facts using Hiera (I honestly haven't used it, just read about it)?


- Ryan

On Tuesday, June 19, 2012 8:32:00 AM UTC-7, Jeff McCune wrote:

Exported data as a concept and mental model is more important than exported resources IMHO.  You've nailed it.

Add me to the list of people who have passed hostnames through exported resources to a reverse proxy when all I really want is a variable containing an up to date list of worker hostnames.

The use cases for exported data outnumber the use cases for exported resources.

If you had an API to set values you could then read using Hiera, would that satisfy your needs?

For example, you could append a hostname to a specific array and would have a puppet sub command action to do this for you.

puppet data append load_balancer_one_workers newworker.example.com

Something like this, but you'd also be able to set the hierarchy point as an option.

--
Jeff McCune

On Tuesday, June 19, 2012 at 3:21 AM, Ryan Bowlby wrote:

I'm bumping up against the apparent limits of puppet. There appears to be a need for the ability to export data and not just resources. Then collecting this data and filtering based on specific values and or node facts. Nature will find a way....

Examples of exported resources being used to overcome lack of exported "data":

- Gary Larriza contributed an haproxy module to the forge which exports a define containing a concat fragment. These are then used to assemble the haproxy config with appropriate balance members.  https://github.com/glarizza/puppet-haproxy

- Dan Bode created puppet-nodesearch to fill this need. I commend the effort but hope a final result would resemble the existing collection and exporting syntax, and generally be more puppety.  https://github.com/puppetlabs/puppetlabs-nodesearch

- Countless puppet-user threads related to abusing the exported file resource, then collecting them in  some tempdir, then doing exec and looping through said files values. :(

Perhaps being able to do something like:

Export a variable to central datastore:

<at> <at> $ganglia_cluster = "www1"

Again with metaparam:

<at> <at> $ganglia_cluster = "www1" { tag => "foo" }

Realize said variables as hash whose key is $::fqdn on another node:

$ganglia_clusters = realize("$ganglia_cluster")

Creating:

{ "some.fq.dn" => "www1", "another.fq.dn" => "mail1" }

or with filtering:

$ganglia_clusters = $ganglia_cluster <<|  tag == "foo" |>>

or with fact filtering

$ganglia_clusters = $ganglia_cluster <<|  tag == "foo" or $::architecture == "i386" |>>

Obviously these examples are crap but I think the idea has some value. Allowing the use of these collected data types within templates would make sense. Doing so in a way that fits with the DSL and isn't overly complicated would add tremendous power.

Thanks,

Ryan Bowlby

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/o2pJGxJSNasJ.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/KgBYoHn5ZwoJ.

To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.