----- Original Message -----
> From: "llowder" <llowde...@gmail.com>
> To: puppet-dev@googlegroups.com
> Sent: Thursday, December 20, 2012 7:05:11 PM
> Subject: Re: [Puppet-dev] hiera and defines
>
>
>
> On Thursday, December 20, 2012 12:47:54 PM UTC-6, Andy Parker wrote:
>
>
> On Thu, Dec 20, 2012 at 10:23 AM, llowder < llow...@gmail.com >
> wrote:
>
>
> I plan on opening a feature request on this, but I wanted to start a
> discussion and get an idea of possibilities and implications before
> I did.
>
> I think it would be nice to be able to use the databinding feature of
> hiera / puppet 3 with defines. Now, since defined types are not
> singletons, it does pose a bit of a problem in terms of addressing.
>
> How problematic would it be to support something like:
>
> define module::mydefine(
> $param1 = 'value'
> ){
> ....
> }
>
> In the node def:
>
> module::mydefine{ 'foo': }
>
> Somewhere in the hiera hierarchy something like:
>
> module::mydefine::foo::param1: 'othervalue'
>
> I know under current setups, the above key would be corresponding to
> a class located at $modulepath/module/manifests/mydefine/foo.pp
>
> but would something like I described even be feasible? Or is there
> another construct that would allow similar usage?
>
> I think that would be feasible. I can't see any problems with that
> format for the data off the top of my head. Another possibility
> might be to have a define expect that the key 'module::mydefine'
> contains a hash of namevar => param-hash. Something like that might
> be nicer, but I don't think it would work as well with the hiera
> lookups.
>
> Once we start doing that though, it seems like for consistency we
> would want to have it also work for non-define types (user, group,
> service, etc.). Is that a sensible way to be going? For instance, if
> we didn't do this all the way, then there would be no way to change
> from a define type to a custom type in a manner that an end user
> would not notice.
>
> Making that available for all types - custom, defined, builtin, could
> have uses, in terms of data separation mostly (that I can think of
> off hand). I can *almost* see this being used to allow an ENC to
> declare individual resources for a node.. but I am not positive that
> is a good idea, or even exactly how it would work (though I think
> the hash key syntax for the classes could be used but I am not very
> familiar with this aspect of puppet)
>
>
>
>
>
>
>
> Thanks.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/67dFxhI3re8J .
> To post to this group, send email to puppe...@googlegroups.com .
> To unsubscribe from this group, send email to
> puppet-dev+...@googlegroups.com .
> 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 view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/gwtMG6-Uw6wJ .
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>
>
> On Thursday, December 20, 2012 12:47:54 PM UTC-6, Andy Parker wrote:
> >
> > On Thu, Dec 20, 2012 at 10:23 AM, llowder <llow...@gmail.com
> > <javascript:>
> > > wrote:
> >
> >> I plan on opening a feature request on this, but I wanted to start
> >> a
> >> discussion and get an idea of possibilities and implications
> >> before I did.
> >>
> >> I think it would be nice to be able to use the databinding feature
> >> of
> >> hiera / puppet 3 with defines. Now, since defined types are not
> >> singletons,
> >> it does pose a bit of a problem in terms of addressing.
> >>
> >> How problematic would it be to support something like:
> >>
> >> define module::mydefine(
> >> $param1 = 'value'
> >> ){
> >> ....
> >> }
> >>
> >> In the node def:
> >>
> >> module::mydefine{ 'foo': }
> >>
> >> Somewhere in the hiera hierarchy something like:
> >>
> >> module::mydefine::foo::param1: 'othervalue'
> >>
> >> I know under current setups, the above key would be corresponding
> >> to a
> >> class located at $modulepath/module/manifests/mydefine/foo.pp
> >>
> >> but would something like I described even be feasible? Or is there
> >> another construct that would allow similar usage?
> >>
> >
> > I think that would be feasible. I can't see any problems with that
> > format
> > for the data off the top of my head. Another possibility might be
> > to have a
> > define expect that the key 'module::mydefine' contains a hash of
> > namevar =>
> > param-hash. Something like that might be nicer, but I don't think
> > it would
> > work as well with the hiera lookups.
> >
> > Once we start doing that though, it seems like for consistency we
> > would
> > want to have it also work for non-define types (user, group,
> > service,
> > etc.). Is that a sensible way to be going? For instance, if we
> > didn't do
> > this all the way, then there would be no way to change from a
> > define type
> > to a custom type in a manner that an end user would not notice.
> >
>
> Making that available for all types - custom, defined, builtin, could
> have uses, in terms of data separation mostly (that I can think of off
> hand). I can *almost* see this being used to allow an ENC to declare
> individual resources for a node.. but I am not positive that is a good idea,
> or
> even exactly how it would work (though I think the hash key syntax for the
> classes could be used but I am not very familiar with this aspect of
> puppet)
yeah, it can get a bit complex, I've played around with these ideas not too
long ago and ended up with an entire new pure data DSL for Puppet where every
property or every resource is overridable by the hierarchy
it's pie in the sky code certainly not intended for any serious use (it was
written at 2am on a plane while I couldnt sleep) but it's an interesting
experiment. It also supports recursive lookups where hiera looking up
data inside itself again which is something quite a few ppl are asking
for
https://github.com/ripienaar/hiera-puppet-nodes#readme
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
