All I'm saying is that I think hashes should be first-class citizens in
Puppet and right now they're not. Every other object can be placed in an
array and easily and scalably declared. Hashes are "special" because you
can declare them like anything else, but you can't use them like anything
else. It may not be a bug but it violates the principle of least surprise
and leaves the newbie confused.
On Wed, Jun 8, 2011 at 11:46 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Jun 8, 11:33 am, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> > If you look at what I tried to do you'll realize that's not the case. I
> > understand what you're saying, but the issue is one of Puppet not
> supporting
> > its own 'syntactic sugar' consistently. I created an array (this is not
> a
> > convenience for a large number of machines, it's a requirement) but since
> > it's an array of hashes rather than an array of strings it doesn't work
> > right.
>
>
> Correction: it doesn't work the way you wish it would. Perhaps it
> defies your intuition, but that doesn't make it wrong. I concur with
> Brian that you seem to be thinking about Puppet DSL in declarative
> terms, and that that really doesn't work.
>
> There are a lot variations on that theme, but perhaps you're running
> into this one: Puppet defined types are not analogous to C macros;
> rather they are bona fide resource types implemented via Puppet DSL.
> People typically hit that from a different angle, but it smacks of the
> same thinking that you even consider using a hash as a resource title,
> much less expect the $name variable inside the definition body to
> refer to the actual object presented as the title of an instance.
>
> Here are some other things you need to know:
>
> The $name variable in a definition body contains the title of an
> instance of the definition. It is a string, by definition.
>
> Whatever object is presented as a resource title is converted to a
> string or to an array of strings, to yield one or more resource
> titles. If the object is neither a string nor an array of strings
> then the result will probably not be what you wanted, but it is
> entirely consistent.
>
>
> > That's a bug, plain and simple. There's no point in having hashes
> > if we can't use defines or virtuals with them without breakage.
>
>
> It seems a little hasty to call "bug" and declare "breakage" over a
> feature you wish Puppet had. Especially so when that feature would be
> inconsistent with the rest of Puppet. I do agree that Puppet hashes
> are less useful than someone with a background in, say, Perl might
> expect. I never use them myself, but some find them useful.
>
> As for having to use an array, much less an array of hashes, how does
> that benefit your example manifest over this:
>
>
> define usertest ($uid) {
> user { "$name":
> ensure => present,
> uid => $uid
> }
> }
>
> @usertest {
> "bill": uid => "12345";
> "ted": uid => "12346";
> }
>
> realize Usertest[bill]
>
>
> That's both cleaner and less verbose than your version, and it scales
> just as well with the number of users. In particular, compare your
> initialization of $users with the @usertest declarations in my
> version. Also, mine will work (modulo any typos that may have crept
> in). I use something much like it myself.
>
>
> John
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
