On Fri, 2010-01-29 at 04:55 -0800, Arnauld wrote:
> > as suggested on the users list, use the config_version field.
>
> It only provides a global configuration versioning and I'd like a per
> class versioning (see tbelow he reason why).
>
> > I still don't see why you would need a per class versioning. Clients
> > are getting one catalog, which contains all the current checked out
> > classes which can be represented by one single version of all your
> > manifests.
>
> Puppet doesn't update configurations in a synchronous way and there's
> no so much control on the scheduler, even by restarting the puppetd
> daemon. The consequence is that it's difficult to know in real time
> which hosts / which modules are updated.
>
> Another reason is that even if the puppetd daemon is running,
> sometimes it does... nothing, or sometimes it makes the job, but very
> slowly.
> Suppose I update a module in my masterpuppet config: I really need to
> know in *real time* which of my 200 (or more) clients have been
> updated by just quickly looking at my CMDB interface. You suggest
> using the config_version field. It looks fine as puppet configuration
> can be seen as a whole thing. But we split that configuration in
> several packages (one per module), which is a very convenient way to
> precisely keep track of every used resources / modules.
>
>
> In fact, I just need to know: how can I be sure, at any time, that a
> client has been updated with the last puppet version and that every
> modules have succesfuly been update ?
> As you said, maybe there's another more convenient way to do this and
> maybe my solution is wrong. But actually, I'm still searching....
This might not be the best solution, but you might use storeconfigs and
a definition called version:
define version($version) {
}
which you'd use as:
class myclass {
version { "myclass":
number => "1.0.1"
}
}
Then when the client would connect to your master, the catalog would be
compiled and you'd have a row for Version["myclass"] with a parameter
"number" of value "1.0.1".
Then it's up to your CMDB tools to display this information.
--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
