On Thursday, August 16, 2012 3:38:10 PM UTC-5, Daniele Sluijters wrote:
I'm afraid I don't completely agree there. One of the benefits of
environments is that it allows you to completely separate a change for a
module/extension into a separate environment, without needing a separate
master, SSL CA and so forth.
I'm sorry, disagreeing with me is not permitted. :-)
Seriously, though, if you use environments only for separating your
production code from your test code and maybe from your development code
then -- to the extent that works for you -- fine. I wouldn't do it that
way, but you're not me (for which I'm sure a great many people are
If you are also using environments for other purposes, however, such as
different environments for different clients, different departments, or the
like, then I think you really lose something, or at least incur a lot
higher cost, by simultaneously using that same dimension to provide for
testing. Note in particular that a separate master does not necessarily
have to have separate CA, certificate, etc.; in fact, if the masters are
colocated on the same host then it should be pretty easy to make them share.
As far as the point to not exposing the production master to untested
code, fair enough. I guess there's a chance that untested Ruby code in a
different environment could crash the master. Then again, I'll probably
notice that about 10 seconds after deploying the actual code and if an
agent can't check in for a few minutes that's not necessarily a problem.
Remember that we're working in Ruby, so code the master loads can
dynamically modify code that's already loaded and running (subject to some
constraints). If I actually *wanted* to crash the master via a custom
extension, then I'm pretty confident that I could do it. I don't have any
doubt that a buggy extension could do it accidentally. Worse than outright
crashes, however, would be subtler misbehaviors that you might not
recognize immediately. Depending on the nature of the misbehavior, a lot
of damage could be caused.
The point that we would be able to test Puppet extensions without putting
them into production is moot really if Puppet would actually bother to load
extensions from a environment specific libdir. There's plenty of ways to
work around the fact that extensions in environments don't really work as
one would expect them to but, that really ought be fixed in the first
place, or environments removed all together. In it's current state the
behaviour is slightly unspecified.
The patch suggested in the ticket seems reasonable enough though I'm
guessing one would have to tell Puppet its libdir now looks like
/var/lib/puppet/master/lib/<%= environment %> for it to work.
I haven't examined the patch, but my main concern would be about related
which concerns different
versions of the same extension being relied upon by different environments
(it doesn't work), and which is explicitly not addressed by the proposed
patch for issue 13858. Where different environments want different
versions of extensions, such as if you're trying to use environments to
provide a testbed for extension development or for third-party module
testing, I would think 12173 would be a blocker.