----- "Luke Kanies" <[email protected]> wrote: > On Jun 9, 2010, at 11:12 AM, R.I.Pienaar wrote: > > > > > ----- "Luke Kanies" <[email protected]> wrote: > > > >> On Jun 9, 2010, at 10:59 AM, R.I.Pienaar wrote: > >> > >>> > >>> ----- "Luke Kanies" <[email protected]> wrote: > >>> > >>>> On Jun 9, 2010, at 10:44 AM, R.I.Pienaar wrote: > >>>>>> > >>>>>> I think a big part of what we're interested in that Ohad has > is > >>>> the > >>>>>> yaml support, rather than CSV. > >>>>> > >>>>> It really is no challenge to get extlookup to speak yaml, > people > >>>>> have it speaking to all sorts of sources even ldap. > >>>>> > >>>>> What would be useful is instead of randomly going picking > >>>>> implementations if you can say what you want to change and I > can > >>>>> look at doing that. > >>>> > >>>> Sorry, I didn't think I was randomly picking implementations - I > >>>> thought I was picking a slightly modified version that already > >>>> supported YAML. > >>>> > >>>> It's easy - I basically just want default support for YAML. > >>>> > >>>>>> > >>>>>> > >>>>>>> isnt right if you're going to merge it. Can you think of a > >> quick > >>>>>>> easy way to improve that? > >>>>>> > >>>>>> What is the global variable problem, again? > >>>>> > >>>>> configuring the search order and behavior of the tools is done > >> with > >>>> > >>>>> a variable in site.pp, which feels very hacky to me. > >>>> > >>>> Seems like adding a setting for them is the appropriate choice, > >>>> right? > >>>> > >>> > >>> Yeah, though being in site.pp it also means they can differ per > >>> environment. Here's an example: > >>> > >>> $extlookup_datadir = "/etc/puppet/manifests/extdata" > >>> $extlookup_precedence = ["%{fqdn}", "foo_%{foo}", "location_% > >>> {location}", "domain_%{domain}", "country_%{country}", "common"] > >> > >> puppet.conf supports environments just fine, right? > > > > yes, just saying, this should be environment aware if we do it. > > > >> > >>> so issues are: > >>> > >>> - they are global variables puppet.conf under the environments > would > >> > >>> be great > >>> - they have these weird %{varname} notation, I believe the need > for > >> > >>> that is fixed in recent puppets but there was some parsing order > >>> weirdness back in the day. > >>> > >>> The, possibly sucky, thing is that those variables like %{foo} > >>> would be within the context of the scope the extlookup() call is > >>> done in, > >>> > >>> class a { > >>> $foo = "bar" > >>> extlookup("test") > >>> } > >>> > >>> class a { > >>> $foo = "blah" > >>> extlookup("test") > >>> } > >>> > >>> > >>> Isn't going to give you the same answer if you have matching data > >>> files, i dont know if we can retain this behavior, make these > >>> settings AND get rid of the strange variable notation. > >> > >> The easy answer is no. If you switch to settings, dynamic scoping > is > >> gone, but I'm happy at that. > > > > hmm, so how would settings potentially look, how would we reference > > > a fact etc in the puppet.conf? > > > > in extlookup essentially I pull out %{...} and just do > > lookupvar("...") and search replace it in there, I can keep doing > > this they are just tokens for search and replace. It just doesnt > > seem overly puppet like to me, introducing fancy new variable rules > > > but thats the best I could do in the context of a parser function. > > > Really I am looking for a way to improve on this. > > Yeah, I don't have much of an answer here. Settings don't support > interpolation outside of settings. You could hack something for > extlookup to use -- e.g., interpolating %foo as a variable in the
yeah, exactly what I do now. OK, well then I guess if you dont find that syntax too offensive then its fine, I'll have a play with yaml support. -- 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.
