hiera and defines

43 views
Skip to first unread message

llowder

unread,
Dec 20, 2012, 1:23:00 PM12/20/12
to puppe...@googlegroups.com
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?

Thanks.

Andy Parker

unread,
Dec 20, 2012, 1:47:54 PM12/20/12
to puppe...@googlegroups.com
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.
 

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.

llowder

unread,
Dec 20, 2012, 2:05:11 PM12/20/12
to puppe...@googlegroups.com


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)

R.I.Pienaar

unread,
Dec 20, 2012, 2:25:27 PM12/20/12
to puppe...@googlegroups.com
> https://groups.google.com/d/msg/puppet-dev/-/gwtMG6-Uw6wJ .
> 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.
>
>
>
> 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:>
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
Reply all
Reply to author
Forward
0 new messages