> 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.... Best regards, Arnauld -- 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.
