On Sep 22, 12:39 pm, Robin Lee Powell <rlpow...@digitalkingdom.org>
wrote:
> Thanks for the detailed reply!
>
> On Thu, Sep 22, 2011 at 07:18:13AM -0700, jcbollinger wrote:
>
> > It sounds like your problem is that you don't in fact want to
> > collect *resources* at all -- rather, you want to collect *data*.
> > That is not what exported resources are for.
>
> That's entirely correct. I knew I was hacking around a "not really
> designed to do this", I just thought it might be possible anyway.
>
> > Exported resources are resources intended to be managed on nodes
> > other than (or in addition to) the one declaring them. There is
> > necessarily an aspect of data sharing to that, but they should not
> > be viewed as a vehicle for data sharing.
>
> OK.
>
> > > It sounds from what people are saying like there really isn't a
> > > reasonable way to do this yet?
>
> > Again, it depends on what "this" is, but I think you are
> > approaching the problem backwards. If you need centralized data
> > then you should create a data source and use it to drive your
> > resource declarations wherever appropriate. Details depend a lot
> > on your general approach and the complexity of the data, but if
> > you want to access your shared data store from within Puppet
> > itself then I'd recommend looking into hiera.
>
> The data right now is *incredibly* simple; just a list of email
> addresses (one for each user defined on each host everywhere).
> Adding a whole data source system just for that seems like
> significant overkill.
>
> Using the @@file trick, while cheating as you say, seems a lot less
> effort until/unless Puppet integrates some method of data sharing.
> Note that by "integrates" there I don't mean "comes with" or
> anything, more like "I can run a couple of yum installs and tweak a
> couple of config variables and it works", which I'm pretty sure
> isn't the case now for any such shared data stores.
You are missing the obvious: anything in your manifests themselves is
at least potentially available to all nodes. Taking your e-mail
address example, you can do this:
class email {
$addresses = {
'alice' => '...@alice.com',
'bob' => '...@bob.com',
...
'zoe' => '...@foo.net'
}
}
There's your data store. You can then remove the 'email' parameter
from users::normal, and instead have it look up the e-mail address:
define users::normal ($id) {
$email = $email::addresses[$name]
...
}
And the whole of $email::addresses is sitting there for any node that
wants it.
That approach works best for fairly simple data, but there's no
inherent barrier to making the data as complex as you like. As a
practical matter, however, you might want to externalize the data so
that you don't have to modify your manifests to update it. That's
part of what a tool such as hiera could do for you: it might, for
example, load the data from a file and present the hash value to you.
Moreover, it abstracts the actual data source so that at the point of
use, your manifests don't need to know whether the data is coming from
DSL variables, a flat file, a database, etc.
Why then, you may ask, are exported resources useful? Why not take a
fully data-driven approach along the lines above? I'm glad you
asked. Exported resources can do something that the above approach
cannot: their properties and even their very existence can depend on
the facts pertinent to the nodes exporting them. If you are
considering a use of exported resources that doesn't somehow leverage
that characteristic, then you are looking at the wrong tool.
John
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
