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.
I'm not sure I understand you, what you mean with "doesn't update
configurations in a synchronous way". Can you elaborate?
If a client requests its catalog it gets a compiled catalog of the
current available manifests and modules. Which can be seen as a
current snapshots what lays on the disk, which can always be uniquely
identified. There is no way that client A and B connecting at the same
time get their own catalog based on different versions of the
available manifests and modules. (except you are using environments
which can still be treated by the script as well.) This means that
every client who gets the client from the master (and not using the
local cached one, which could be disabled as well) will get the _same_
config_version. If a client doesn't get the catalog from the master
and applies the local cached one it will report (in logs and reports)
with the _old_ config_version.
This means that if you know the current global version, you can easily
spot those who aren't on that one.
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.
I don't see how using modules interfere to look at the configuration
as one big thing. What the client gets is one big thing and if only
one part of that big thing changes the version changes globally as well.
I agree that having a direct per class version is easier to spot in
detail, but this detail can a) be derived from the global version and
b) assuming you have a lot of classes very verbose.
Assuming that you want to know which clients have been updated to the
current checked out version on the master in my opinion it is
sufficient to know which clients have applied the current global
version, as the per class version can be derived from the global
version.
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....
Let me outline different possible setups:
* You have one big repository containing all the modules -> one global
version.
* You have one main repository containing site.pp and some other small
files, but you want to have each module is in its own repository. You
have 2 options:
** checking out each module-repository individually iterating over all
available repositories. config_version would need a way to generate an
overall unique version, which can indeed be tricky, but is possible to
do. -> one global version.
** having each module-repository as an own git-submodule (svn has
similar possibilities) in the main repository. Git forces you commit a
checked out tuple of submodules in the main repository in as own
commit. Which means that a commit in the global repository uniquely
identifies each version of the submodules. -> one global version
As long as I didn't miss something really important I think you can do
what you want with already existing tools. And remember:
config_version will be anything the script outputs, your free to put
in there what you like to put in.
As a sidenote, I would rather relay on a version information from a
VCS than one manually added by devops. If you are interested in
spotting which client haven't yet applied the latest version, what do
you do if somebody forgets to update the version? Which can happen
very often in a manually driven versioning environment.
cheers pete
--
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.
