Hmmm, either I''m doing something wrong or virtual resources are incompatible with hashes. When I do this: $users = [{ username => "bill", uid => "12345" }, { username => "ted", uid => "12346" }] define usertest ($alias = $name[username]) { user {$name[username]: ensure => present, uid => $name[uid] } } @usertest { $users: } realize Usertest[bill] I get this: warning: alias is a metaparam; this value will inherit to all contained resources Failed to realize virtual resources Usertest[bill] on node Which seems unfortunate. Hash support is a really cool idea but I keep tripping over parts of Puppet that don''t handle it well. -- 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 Jun 7, 6:15 pm, Aaron Grewell <aaron.grew...@gmail.com> wrote:> Hmmm, either I''m doing something wrong or virtual resources are incompatible > with hashes.I think it''s a mix of about two parts "doing something wrong" to one part "incompatible", coming out to more or less "Puppet doesn''t do what I wish it would."> When I do this: > $users = [{ username => "bill", uid => "12345" }, > { username => "ted", uid => "12346" }] > > define usertest ($alias = $name[username]) { > user {$name[username]: > ensure => present, > uid => $name[uid] > }} > > @usertest { $users: } > realize Usertest[bill] > > I get this: > warning: alias is a metaparam; this value will inherit to all contained > resources > Failed to realize virtual resources Usertest[bill] on node > > Which seems unfortunate. Hash support is a really cool idea but I keep > tripping over parts of Puppet that don''t handle it well.In a resource declaration, Puppet expects the value or variable preceding the colon ($users in your example) to be a resource title or an array of resource titles. I find it somewhat surprising that Puppet accepted your hash for the resource titles, but I suppose it flattens the hash into an ordinary array. It would be nice if that elicited at least a warning. Do not be confused by the similar DSL syntax: resource declarations are completely unrelated to hashes at the DSL level. I guess you hoped Puppet would unpack the hash into a resource title and properties, but it just doesn''t, and I wouldn''t expect it to do. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Here''s the thing though: since arrays are the only native method of looping, Puppet needs to handle arrays of all native types well. If it doesn''t, from an end-user perspective that''s broken. On Wed, Jun 8, 2011 at 8:36 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Jun 7, 6:15 pm, Aaron Grewell <aaron.grew...@gmail.com> wrote: > > Hmmm, either I''m doing something wrong or virtual resources are > incompatible > > with hashes. > > > I think it''s a mix of about two parts "doing something wrong" to one > part "incompatible", coming out to more or less "Puppet doesn''t do > what I wish it would." > > > > When I do this: > > $users = [{ username => "bill", uid => "12345" }, > > { username => "ted", uid => "12346" }] > > > > define usertest ($alias = $name[username]) { > > user {$name[username]: > > ensure => present, > > uid => $name[uid] > > }} > > > > @usertest { $users: } > > realize Usertest[bill] > > > > I get this: > > warning: alias is a metaparam; this value will inherit to all contained > > resources > > Failed to realize virtual resources Usertest[bill] on node > > > > Which seems unfortunate. Hash support is a really cool idea but I keep > > tripping over parts of Puppet that don''t handle it well. > > > In a resource declaration, Puppet expects the value or variable > preceding the colon ($users in your example) to be a resource title or > an array of resource titles. I find it somewhat surprising that > Puppet accepted your hash for the resource titles, but I suppose it > flattens the hash into an ordinary array. It would be nice if that > elicited at least a warning. > > Do not be confused by the similar DSL syntax: resource declarations > are completely unrelated to hashes at the DSL level. I guess you hoped > Puppet would unpack the hash into a resource title and properties, but > it just doesn''t, and I wouldn''t expect it to do. > > > 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+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.
On Jun 8, 2011, at 8:45 AM, Aaron Grewell wrote:> Here''s the thing though: since arrays are the only native method of looping, Puppet needs to handle arrays of all native types well. If it doesn''t, from an end-user perspective that''s broken.See, there''s the crux of the issue: arrays are *not* a method of looping. Puppet''s DSL is declarative, not procedural (imperative). What you are thinking of as "looping" is simply a convenient shorthand (syntactic sugar is the appropriate term). If you are thinking in procedural terms (which we''ve all done at one point or another), you''re simply going to run around in circles ranting that Puppet is broken until you get your head wrapped around its declarative nature (much like I did/do). Puppet is not procedural. Never has been, never will be. You can probably meet your needs by thinking about the desired state in different terms and using extlookup, or using custom functions. If you are really insane, you can modify the Puppet backend to execute a file and read the output instead of reading the file directly, which might allow you to dynamically generate the manifests you want applied, though the added complexity may well be a net loss. In short, if you are thinking "procedural", then you have not yet drunk the Kool-Aide. Join us. -- 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.
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. 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. On Wed, Jun 8, 2011 at 9:01 AM, Brian Gallew <geek@gallew.org> wrote:> On Jun 8, 2011, at 8:45 AM, Aaron Grewell wrote: > > > Here''s the thing though: since arrays are the only native method of > looping, Puppet needs to handle arrays of all native types well. If it > doesn''t, from an end-user perspective that''s broken. > > See, there''s the crux of the issue: arrays are *not* a method of looping. > Puppet''s DSL is declarative, not procedural (imperative). What you are > thinking of as "looping" is simply a convenient shorthand (syntactic sugar > is the appropriate term). If you are thinking in procedural terms (which > we''ve all done at one point or another), you''re simply going to run around > in circles ranting that Puppet is broken until you get your head wrapped > around its declarative nature (much like I did/do). Puppet is not > procedural. Never has been, never will be. > > You can probably meet your needs by thinking about the desired state in > different terms and using extlookup, or using custom functions. If you are > really insane, you can modify the Puppet backend to execute a file and read > the output instead of reading the file directly, which might allow you to > dynamically generate the manifests you want applied, though the added > complexity may well be a net loss. > > In short, if you are thinking "procedural", then you have not yet drunk the > Kool-Aide. Join us. > > -- > 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.
I suspect the root of the problem I''m running into may be the simple nature of $name. It''s not capable of being an arbitrary object. I consider that an architectural issue in a system that supports hashes which are structured objects that can''t really be reduced to a string. IMHO for a future version there should be a $object (or similar) builtin for handling hashes as names/titles of resources. $name should magic-map to $object[name] for hash-type objects to make life easier for those of us who want to use hashes. On Wed, Jun 8, 2011 at 9:33 AM, Aaron Grewell <aaron.grewell@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. 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. > > > On Wed, Jun 8, 2011 at 9:01 AM, Brian Gallew <geek@gallew.org> wrote: > >> On Jun 8, 2011, at 8:45 AM, Aaron Grewell wrote: >> >> > Here''s the thing though: since arrays are the only native method of >> looping, Puppet needs to handle arrays of all native types well. If it >> doesn''t, from an end-user perspective that''s broken. >> >> See, there''s the crux of the issue: arrays are *not* a method of looping. >> Puppet''s DSL is declarative, not procedural (imperative). What you are >> thinking of as "looping" is simply a convenient shorthand (syntactic sugar >> is the appropriate term). If you are thinking in procedural terms (which >> we''ve all done at one point or another), you''re simply going to run around >> in circles ranting that Puppet is broken until you get your head wrapped >> around its declarative nature (much like I did/do). Puppet is not >> procedural. Never has been, never will be. >> >> You can probably meet your needs by thinking about the desired state in >> different terms and using extlookup, or using custom functions. If you are >> really insane, you can modify the Puppet backend to execute a file and read >> the output instead of reading the file directly, which might allow you to >> dynamically generate the manifests you want applied, though the added >> complexity may well be a net loss. >> >> In short, if you are thinking "procedural", then you have not yet drunk >> the Kool-Aide. Join us. >> >> -- >> 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.
On Tue, Jun 7, 2011 at 4:15 PM, Aaron Grewell <aaron.grewell@gmail.com> wrote:> $users = [{ username => "bill", uid => "12345" }, > { username => "ted", uid => "12346" }]Aaron, I think this is a completely sane request. We''ve talked about it before, but I can''t find an existing ticket. This one seems close, but very old; will you take a look? http://projects.puppetlabs.com/issues/1858 If we can work out a good syntax we''ll put this on the roadmap. I know some of our PS guys are eager for it, too. r -- 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.
The request in the ticket is related but might not solve the same problem. What I think I''m looking for is the generic ability to specify an array of hashes as a resource title and have Puppet handle it intelligently (that is, produce a locally scoped hash split from the array and easily accessible inside the resource specification as well as knowing what value it should use for $name or supporting e.g. $alias => hash[key] for specifying the appropriate value). The reason I think that''s preferable to the ability to transform a hash to a resource is because it will work everywhere. What I don''t know is whether the hash -> resource transform can be made to declare an instance of a define(). If so, it would handle my needs quite well. If OTOH it will only declare native resource types then it won''t do all of what I''m looking for. It would be a step in the right direction though. On Wed, Jun 8, 2011 at 10:17 AM, Randall Hansen <randall@puppetlabs.com>wrote:> On Tue, Jun 7, 2011 at 4:15 PM, Aaron Grewell <aaron.grewell@gmail.com> > wrote: > > > $users = [{ username => "bill", uid => "12345" }, > > { username => "ted", uid => "12346" }] > > Aaron, I think this is a completely sane request. We''ve talked about > it before, but I can''t find an existing ticket. This one seems close, > but very old; will you take a look? > http://projects.puppetlabs.com/issues/1858 > > If we can work out a good syntax we''ll put this on the roadmap. I > know some of our PS guys are eager for it, too. > > r > > -- > 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.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jun 8, 12:17 pm, Randall Hansen <rand...@puppetlabs.com> wrote:> On Tue, Jun 7, 2011 at 4:15 PM, Aaron Grewell <aaron.grew...@gmail.com> wrote: > > $users = [{ username => "bill", uid => "12345" }, > > { username => "ted", uid => "12346" }] > > Aaron, I think this is a completely sane request. We''ve talked about > it before, but I can''t find an existing ticket. This one seems close, > but very old; will you take a look?http://projects.puppetlabs.com/issues/1858 > > If we can work out a good syntax we''ll put this on the roadmap. I > know some of our PS guys are eager for it, too.I agree that the concept is reasonable, but I suggest that you consider implementing it as a new built-in function. Puppet''s current DSL syntax is arcane enough already -- consider all the feedback from PC EU to that effect. A function for this purpose might be something like this: declare($type, $properties, $title_key="title") $type: the name of the resource type $properties: a hash or array of hashes of properties for the resources to declare $title_key: the key, which must be present in each hash, from which the title of the corresponding resource instance is obtained Probably you also need a parameter to select concrete vs. virtual vs. exported declaration, or else different flavors of the function to support those alternatives. Example: $users = [ { username => "bill", uid => 501 }, { username => "ted", uid => 502 } ] declare("User", $users, "username") Be excellent to each other, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.Bollinger@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+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.
On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell <aaron.grewell@gmail.com> wrote:> All I''m saying is that I think hashes should be first-class citizens in > Puppet and right now they''re not.I agree with that as a high-level problem statement, but to make progress we need to put legs on it. John''s got one possibility: a new built-in function. I agree with him that the DSL is too crufty, but I don''t think this needs to add to it if done well. Here''s another possibility, I think: http://groups.google.com/group/puppet-users/browse_thread/thread/162d86ed39d6d8da What do you think? I must admit not to understand all the details. As D. UX I mostly try to squeeze ideas out of other people. :) I''ll try to keep the conversation going and help us coalesce around the details, but I''ll need help from people who really have skin in the game. Thanks, r -- 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.
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. On Wed, Jun 8, 2011 at 12:58 PM, Randall Hansen <randall@puppetlabs.com>wrote:> On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell <aaron.grewell@gmail.com> > wrote: > > > All I''m saying is that I think hashes should be first-class citizens in > > Puppet and right now they''re not. > > I agree with that as a high-level problem statement, but to make > progress we need to put legs on it. John''s got one possibility: a > new built-in function. I agree with him that the DSL is too crufty, > but I don''t think this needs to add to it if done well. > > Here''s another possibility, I think: > > http://groups.google.com/group/puppet-users/browse_thread/thread/162d86ed39d6d8da > > What do you think? I must admit not to understand all the details. > As D. UX I mostly try to squeeze ideas out of other people. :) I''ll > try to keep the conversation going and help us coalesce around the > details, but I''ll need help from people who really have skin in the > game. > > Thanks, > > r > > -- > 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.
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.2.7.x merged the older "hash2resource" function as "create_resource" https://github.com/puppetlabs/puppet/blob/2.7.x/lib/puppet/parser/functions/create_resources.rb I''m actually not sure where the definitive home for hash2resource is, perhaps someone else will chime in.> > > > On Wed, Jun 8, 2011 at 12:58 PM, Randall Hansen <randall@puppetlabs.com>wrote: > >> On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell <aaron.grewell@gmail.com> >> wrote: >> >> > All I''m saying is that I think hashes should be first-class citizens in >> > Puppet and right now they''re not. >> >> I agree with that as a high-level problem statement, but to make >> progress we need to put legs on it. John''s got one possibility: a >> new built-in function. I agree with him that the DSL is too crufty, >> but I don''t think this needs to add to it if done well. >> >> Here''s another possibility, I think: >> >> http://groups.google.com/group/puppet-users/browse_thread/thread/162d86ed39d6d8da >> >> What do you think? I must admit not to understand all the details. >> As D. UX I mostly try to squeeze ideas out of other people. :) I''ll >> try to keep the conversation going and help us coalesce around the >> details, but I''ll need help from people who really have skin in the >> game. >> >> Thanks, >> >> r >> >> -- >> 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. >-- Nigel Kersten Product, Puppet Labs @nigelkersten -- 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.
Nice! More good things to look forward to. :) On Wed, Jun 8, 2011 at 1:58 PM, Nigel Kersten <nigel@puppetlabs.com> wrote:> > > 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. > > > 2.7.x merged the older "hash2resource" function as "create_resource" > > > https://github.com/puppetlabs/puppet/blob/2.7.x/lib/puppet/parser/functions/create_resources.rb > > I''m actually not sure where the definitive home for hash2resource is, > perhaps someone else will chime in. > > > > > >> >> >> >> On Wed, Jun 8, 2011 at 12:58 PM, Randall Hansen <randall@puppetlabs.com>wrote: >> >>> On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell <aaron.grewell@gmail.com> >>> wrote: >>> >>> > All I''m saying is that I think hashes should be first-class citizens in >>> > Puppet and right now they''re not. >>> >>> I agree with that as a high-level problem statement, but to make >>> progress we need to put legs on it. John''s got one possibility: a >>> new built-in function. I agree with him that the DSL is too crufty, >>> but I don''t think this needs to add to it if done well. >>> >>> Here''s another possibility, I think: >>> >>> http://groups.google.com/group/puppet-users/browse_thread/thread/162d86ed39d6d8da >>> >>> What do you think? I must admit not to understand all the details. >>> As D. UX I mostly try to squeeze ideas out of other people. :) I''ll >>> try to keep the conversation going and help us coalesce around the >>> details, but I''ll need help from people who really have skin in the >>> game. >>> >>> Thanks, >>> >>> r >>> >>> -- >>> 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. >> > > > > -- > Nigel Kersten > Product, Puppet Labs > @nigelkersten > > -- > 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.
Sirtaj Singh Kang
2011-Jun-09 06:33 UTC
Re: [Puppet Users] Re: Virtual resources and hashes
On 08-Jun-11, at 9:31 PM, Brian Gallew wrote: [snip]> > See, there''s the crux of the issue: arrays are *not* a method of > looping. Puppet''s DSL is declarative, not procedural (imperative).This isn''t precisely true - every pure functional language I''ve seen has some sort of list map and filter, otherwise nothing useful could get done. IMHO there is a mismatch somewhere between the actual domain and the DSL, but it''s hard to identify precisely what it is. -Taj. -- 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 Jun 9, 1:33 am, Sirtaj Singh Kang <sirtaj.k...@gmail.com> wrote:> On 08-Jun-11, at 9:31 PM, Brian Gallew wrote: > [snip] > > > > > See, there''s the crux of the issue: arrays are *not* a method of > > looping. Puppet''s DSL is declarative, not procedural (imperative). > > This isn''t precisely true - every pure functional language I''ve seen > has some sort of list map and filter, otherwise nothing useful could > get done.What do functional languages have to do with it? Puppet is not a functional language either. Indeed, Puppet DSL doesn''t *do* anything -- rather, it *describes*. In particular, it describes system configurations. If you like, you can view your Puppet manifests as constituting metaconfiguration for the Puppet agent, but they are in no sense executable. That''s the point. XML doesn''t have a looping construct either, and its productive uses are legion.> IMHO there is a mismatch somewhere between the actual domain and the > DSL, but it''s hard to identify precisely what it is.I can''t rule out so vague an assertion, but Puppet DSL''s domain model and overall architecture have always seemed on target to me. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Part of the challenge is that I haven''t seen a generally accepted language that succinctly describes what arrays do. If I had it to say again I would have said arrays are Puppet''s only available declarative multiplier. On Thu, Jun 9, 2011 at 7:21 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Jun 9, 1:33 am, Sirtaj Singh Kang <sirtaj.k...@gmail.com> wrote: > > On 08-Jun-11, at 9:31 PM, Brian Gallew wrote: > > [snip] > > > > > > > > > See, there''s the crux of the issue: arrays are *not* a method of > > > looping. Puppet''s DSL is declarative, not procedural (imperative). > > > > This isn''t precisely true - every pure functional language I''ve seen > > has some sort of list map and filter, otherwise nothing useful could > > get done. > > > What do functional languages have to do with it? Puppet is not a > functional language either. Indeed, Puppet DSL doesn''t *do* anything > -- rather, it *describes*. In particular, it describes system > configurations. If you like, you can view your Puppet manifests as > constituting metaconfiguration for the Puppet agent, but they are in > no sense executable. That''s the point. > > XML doesn''t have a looping construct either, and its productive uses > are legion. > > > > IMHO there is a mismatch somewhere between the actual domain and the > > DSL, but it''s hard to identify precisely what it is. > > > I can''t rule out so vague an assertion, but Puppet DSL''s domain model > and overall architecture have always seemed on target to me. > > > 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+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.
Sirtaj Singh Kang
2011-Jun-09 15:23 UTC
Re: [Puppet Users] Re: Virtual resources and hashes
(apologies for the derail) On 09-Jun-11, at 7:51 PM, jcbollinger wrote: [snip]> On Jun 9, 1:33 am, Sirtaj Singh Kang <sirtaj.k...@gmail.com> wrote: >> On 08-Jun-11, at 9:31 PM, Brian Gallew wrote: >> [snip] >>> See, there''s the crux of the issue: arrays are *not* a method of >>> looping. Puppet''s DSL is declarative, not procedural (imperative). >> >> This isn''t precisely true - every pure functional language I''ve seen >> has some sort of list map and filter, otherwise nothing useful could >> get done. > > > What do functional languages have to do with it? Puppet is not a > functional language either.Pure functional languages are the first class of pure declarative languages that came to my mind. Perhaps a better example would have been RDF or Prolog.> XML doesn''t have a looping construct either, and its productive uses > are legion.I don''t see the language as similar to XML, since few people like to write XML by hand.> I can''t rule out so vague an assertion, but Puppet DSL''s domain model > and overall architecture have always seemed on target to me.Fair enough, I agree it was a nebulous statement. I see a shortcoming in dealing with parameterized collections of resources, but I am having trouble articulating what a better system would look like. -Taj. -- 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.