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=... -- 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.
