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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Virtual resources and hashes
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
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.bollin...@stjude.orgwrote: 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+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.
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Virtual resources and hashes
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
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.bollin...@stjude.orgwrote:
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+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.
Re: [Puppet Users] Re: Virtual resources and hashes
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 g...@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+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.
Re: [Puppet Users] Re: Virtual resources and hashes
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.grew...@gmail.comwrote: 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 g...@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+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.
[Puppet Users] Re: Virtual resources and hashes
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.
[Puppet Users] Re: Virtual resources and hashes
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
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.orgwrote:
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.
Re: [Puppet Users] Re: Virtual resources and hashes
On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell aaron.grew...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
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 rand...@puppetlabs.comwrote: On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell aaron.grew...@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+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.
Re: [Puppet Users] Re: Virtual resources and hashes
On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell aaron.grew...@gmail.comwrote: 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 rand...@puppetlabs.comwrote: On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell aaron.grew...@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+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. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Virtual resources and hashes
Nice! More good things to look forward to. :) On Wed, Jun 8, 2011 at 1:58 PM, Nigel Kersten ni...@puppetlabs.com wrote: On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell aaron.grew...@gmail.comwrote: 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 rand...@puppetlabs.comwrote: On Wed, Jun 8, 2011 at 12:07 PM, Aaron Grewell aaron.grew...@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+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. -- 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+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.
