Puppet users - Jun 2011 - two possibilities for declaring resources with hashes [was: Virtual resources and hashes]

I think Aaron lays out the options pretty well.  This issue has been
hanging fire for quite a while, and it would be nice to come to a
decision about what our path forward is.

Who else cares about this?  What do you think?

r

On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell <aaron.grewell@gmail.com>
wrote:
> We''ve looked at two different possibilities thus far:
>
> 1) Make all resource types hash-aware.  This is what I was originally
asking
> for.  It would mean changing the way resources are declared so that in the
> case of a hash their representation of $name was appropriate for use with
> defines and virtuals.  This could either be done by requiring the hash to
> have a ''name'' key and using that or by creating a
metaparameter like
> hash_key so it could be user-specified.  The hash itself would need to be
> passed to the resource in the same way as $name but with a different
> identifier so that its keys could be accessed inside the resource as e.g.
> $data[key].
>
> The upside of this is that it should work universally and conceptually
match
> the rest of Puppet, the downsides I see so far are that its implementation
> might well be intrusive and it might also add to the DSL.
>
> 2) Create a hash -> resource transformation function.  If I understood
John
> correctly this is what he was in favor of.
>
> The upside of this is it should be less intrusive, easier to implement, and
> require no DSL changes.  The downside is that it still makes hashes special
> and requires separate handling of them.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

So, I care some about this: pretty much every place we want to do this
feels very, very much like a work-around to the inability to interact
with meaningful information through either recursion, or iteration, in
the Puppet DSL.  People end up contorting around like snakes to try
and figure out some way to work around other shortfalls of the
language and wind up here.

In my view, rather than creating a second, entirely parallel syntax
for the Puppet DSL to express resources, we should identify what the
individual underlying problems are, solve them, and keep an overall
simpler and cleaner system.

...and, yes, I *do* think that having the ability to use either a
hash, or a resource, to model a resource is creating a second, shadow
language for Puppet resource declaration.

Daniel

On Mon, Jun 13, 2011 at 10:18, Randall Hansen <randall@puppetlabs.com>
wrote:
> I think Aaron lays out the options pretty well.  This issue has been
> hanging fire for quite a while, and it would be nice to come to a
> decision about what our path forward is.
>
> Who else cares about this?  What do you think?
>
> r
>
> On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell
<aaron.grewell@gmail.com> wrote:
>> We''ve looked at two different possibilities thus far:
>>
>> 1) Make all resource types hash-aware.  This is what I was originally
asking
>> for.  It would mean changing the way resources are declared so that in
the
>> case of a hash their representation of $name was appropriate for use
with
>> defines and virtuals.  This could either be done by requiring the hash
to
>> have a ''name'' key and using that or by creating a
metaparameter like
>> hash_key so it could be user-specified.  The hash itself would need to
be
>> passed to the resource in the same way as $name but with a different
>> identifier so that its keys could be accessed inside the resource as
e.g.
>> $data[key].
>>
>> The upside of this is that it should work universally and conceptually
match
>> the rest of Puppet, the downsides I see so far are that its
implementation
>> might well be intrusive and it might also add to the DSL.
>>
>> 2) Create a hash -> resource transformation function.  If I
understood John
>> correctly this is what he was in favor of.
>>
>> The upside of this is it should be less intrusive, easier to implement,
and
>> require no DSL changes.  The downside is that it still makes hashes
special
>> and requires separate handling of them.
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Jun 13, 2011 at 10:18 AM, Randall Hansen
<randall@puppetlabs.com>wrote:
> I think Aaron lays out the options pretty well.  This issue has been
> hanging fire for quite a while, and it would be nice to come to a
> decision about what our path forward is.
>
> Who else cares about this?  What do you think?
>
> r
>
> On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell
<aaron.grewell@gmail.com>
> wrote:
> > We''ve looked at two different possibilities thus far:
> >
> > 1) Make all resource types hash-aware.  This is what I was originally
> asking
> > for.  It would mean changing the way resources are declared so that in
> the
> > case of a hash their representation of $name was appropriate for use
with
> > defines and virtuals.  This could either be done by requiring the hash
to
> > have a ''name'' key and using that or by creating a
metaparameter like
> > hash_key so it could be user-specified.  The hash itself would need to
be
> > passed to the resource in the same way as $name but with a different
> > identifier so that its keys could be accessed inside the resource as
e.g.
> > $data[key].
> >
> > The upside of this is that it should work universally and conceptually
> match
> > the rest of Puppet, the downsides I see so far are that its
> implementation
> > might well be intrusive and it might also add to the DSL.
> >
> > 2) Create a hash -> resource transformation function.  If I
understood
> John
> > correctly this is what he was in favor of.
> >
> > The upside of this is it should be less intrusive, easier to
implement,
> and
> > require no DSL changes.  The downside is that it still makes hashes
> special
> > and requires separate handling of them.
>
As an additional upside, this already exists in 2.7 and is called
create_resources

There is discussion around this topic at:

http://projects.puppetlabs.com/issues/5909


>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.