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