On 6/7/2010 12:19 AM, Markus Roberts wrote:
David --
If I'm understanding you correctly, this is completely opposite of what
was discussed at puppet camp (which leads me to suspect that I'm not
understanding you correctly).
My understanding is that the situation can be broken down into several
steps:
* Instead of having a single namevar, we have a non-empty collection
of them, and two resources are the same if and only if all of them
match. Note that the present situation is a special case of this,
where the collection always has exactly one member.
* As currently, namevar is determined by the type.
* Instead just of inferring the single namevar from the title we let
types decompose the title into values for several (perhaps all) of
the namevar components; note that the present situation is again a
special case of this.
* As a natural extension of the above, we discussed permitting
Brice's hash notation in the same role.
That's the internal/implementation side of it. Please see below for
explainations about the frills I added for the more "user"/developer
oriented spec in my mail.
At no time that I recall were we talking about "title generation", using
a generated title for uniqueness, or this just being a documentation
convention.
We didn't talk about it. But how would puppet reference the following
resources in a log message?
mysql_user {
"frob": host => "web1";
"frob": host => "web2";
"frob": host => "web3";
}
Shouldn't that be called 'Mysql_user["f...@web1"]' and so on? Since the
manifest doesn't provide that "f...@web" string anywhere, the type must
generate it and the implementor should explicitly choose how.
Also the question arose around Trevor's mail how storedconfig's
resources.title is filled. Which, like the log message, is more of a
usability thing than anything else, because the user would expect a
"well-formed" title, that corresponds to the specified parameters,
independently of how they are specified.
The stuff about automatically generating documentation from patterns was
added by me, when drafting the spec. Substituting the parameter names
into the match groups was a seemingly easy way to generate passable
docstrings from the existing information.
Best Regards, David
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
