Not that I want to fight over which versions gets in, but my implementation already supports yaml and module lookup (based on the client environment).
cheers, Ohad On Wed, Jun 9, 2010 at 11:36 PM, R.I.Pienaar <[email protected]> wrote: > > ----- "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]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- 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.
