On May 18, 2010, at 1:44 PM, Nigel Kersten wrote:
On Tue, May 18, 2010 at 1:40 PM, Luke Kanies <[email protected]>
wrote:
On May 18, 2010, at 9:58 AM, Nigel Kersten wrote:
On Tue, May 18, 2010 at 9:40 AM, Luke Kanies <[email protected]>
wrote:
On May 17, 2010, at 8:10 PM, Nigel Kersten wrote:
On Mon, May 17, 2010 at 5:34 PM, Luke Kanies <[email protected]>
wrote:
Hi all,
I'm working two Environment tickets:
http://projects.puppetlabs.com/issues/3517
http://projects.puppetlabs.com/issues/2834
I was reminded that I made the decision not to require site.pp any
more - if you're using an external node classifier and modules,
then this file would often end up empty, so it makes no sense to
require it.
However, I just realized an annoying repercussion of this fact:
We now can't easily tell if an environment is real or fat-fingered.
At least, this is true if you're using node constructs -- if
you're using an external node classifier, I assume it would refer
to classes which Puppet wouldn't be able to look up because the
module path wouldn't resolve correctly.
Normally you'd require that site.pp exist, and then it would have
node information that resulted in classes being looked up in the
module path, etc.
So, the question becomes, is this a bug? I assume so, but I don't
know how to fix it. What defines whether an environment exists?
We used to require environments be strictly listed, but we stopped
that at the request of the community.
Not really though? We did have a list of them as well as a list of
environment definitions, now we just have a list of environment
definitions. Isn't that our authoritative info on whether an
environment exists or not? What is an environment if you haven't
defined *something* in a [environment_name] block in the server
config file?
None of this stuff is really modeled in Puppet right now, though -
you can ask the Settings instance for an environment-specific
setting, but you can't actually ask it what the defined
environments are.
We'd have to add that "does an environment exist?" modeling to
Settings, which would get a bit confusing because executables and
environments can both have sections in puppet.conf.
This seems problematic long term. So we can't have environments
called "main" "puppet" "puppetd" "puppetmasterd" etc ? I'd never
thought of that implication. Given all the attributes of an
environment can also be attributes of an executable, we can't
really tell the difference.
The config parser must know about the valid executables though
right? Anything else has to be an environment doesn't it?
Heh. The config parser in no way knows the valid executables. :)
This is all completely ad-hoc; someone asks for something or sets
something, we treat it a certain way.
Sounds like we should start modeling it, but... I think that's going
to wait for the next release.
Is the answer as simple as another level of hierarchy?
[environments]
[foo]
modulepath=...
[bar]
modulepath=...
It's only that simple if someone else does the work. :)
Remember that these are INI files - there's no such thing as a
heirarchy.
--
I worry that the person who thought up Muzak may be thinking up
something else. -- Lily Tomlin
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
