On Thu, Jan 20, 2011 at 07:51, Iconoplasty <iconopla...@gmail.com> wrote:
> On Jan 4, 12:39 pm, Daniel Pittman <dan...@rimspace.net> wrote:
>
>> That doesn't solve the problem: if the puppet master is half way through a
>> compilation run and you switch the repo under it, you will still see it use
>> mixed versions - because loading the catalog is not atomic either, and
>> neither is file serving.
>>
>> You actually do need to shut down the puppet master (or have it natively
>> support the VCS like it presently does disk) for this to be truely atomic.
>
> Based on the way subversion and git get mentioned in much of the
> introductory documentation for puppet, I'd assumed they were both
> natively supported. I guess not.
Hey there. So, when I wrote "natively supported" I meant that the
puppet master would need to know how to talk directly to the version
control system rather than the file system, such as talking to an SVN
repository over HTTP to fetch the catalog during compilation.
It doesn't, but that doesn't make those tools in any way useless or
anything like that. The problem is, as a few people here have said,
not really an issue in the real world, even if there is a theoretical
race and all. (...and, I should add, it is entirely non-trivial to
define the "correct" behaviour in the face of concurrent updates to a
version control repository as well.)
> Given that's the case, wouldn't it make sense to have the puppet
> client that runs on the puppetmaster server be responsible for
> regularly updating the manifest directory from the VCS, and have that
> update process stop puppetmaster first, and restart it after?
Probably not, especially because that will be more disruptive to the
clients you have out in the wild than the current issue is.
Now, if you really wanted to engineer around it a better approach
might be to deploy mcollective, deploy the puppetcommander extension,
and use that exclusively for scheduling puppet runs on clients.
Then you have a central place (puppetcommander) running on the master
able to control when agents are going to check in or not. It could be
extended to integrate a "VCS update" phase between triggering puppet
agent runs.
That would let you get rid of the race, and the risk of interrupting a
running puppet agent, by pulling the knowledge about which machines
are doing what into a central place, and that is the *only* way
without substantial changes in the master that would, in effect,
implement the same thing.
However, getting mcollective running, deploying puppetcommander, and
all the stack that they depend on is a non-trivial undertaking. You
can probably imagine why it isn't our first port of call for new
users. :)
Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
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.
