Hi Jesse -- I think this is getting pretty close, but you're right this
would not work without a major version bump. Some comments/questions from
the thread--
- The 'creeping perlism' of more sigils seems to be pretty unpopular,
instead most people favour concrete syntax like your example below
- Erik had concerns about using hiera data outside of Puppet - is this a
common use case? we're looking at moving hiera closer to puppet (i.e. for
data in modules) and if we can move to a single codebase there it
simplifies things a fair bit (i.e. relying on future parser) at the expense
of hiera-without-puppet. Is it using hiera as a library that's important or
specifically the command-line program?
- Exploring that line of thought further, what if the right-hand-side value
could contain Puppet DSL expressions? Obviously this opens the door to some
crazy stuff -- I already have concern with putting code back into data and
this goes further down the path, but y'all have pretty convincing use cases
for increasing sophistication in hiera, so it seems worth thinking about
taking it to the logical extension.
- Reading through Wil's example is really interesting because it also
touches on module reusability and module APIs. Are others on the thread in
a similar situation, where you need to compose/abstract common config
parameters to reduce duplication across your site data hierarchy? (And Wil,
is there a reason you can't just do that 'ldap_login_server_uris' mapping
at class declaration time rather than putting the lookups into the class
definitions themselves?)
eric0
On Friday, June 28, 2013 7:45:05 AM UTC-7, Jesse Hathaway wrote:
>
> If there are concerns with adding a new sigil '^', which is not obviously
> intuitive, then I would propose keeping only one sigil for interpolation
> '%' but being explicit on the type of lookup performed.
>
> Examples:
>
> 1. Scope lookup of `potto01_ip`:
> 1. webserver_ip: "%{scope("potto01_ip")}"
> 2. Hiera lookup of `potto01_ip`
> 1. webserver_ip: "%{hiera("potto01_ip")}"
>
> This obviously breaks current scope lookups and would need to be deferred
> to a 2.0 version, but I think it is better to break compatibility rather
> than cluttering up the language in inconsistent ways.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
