-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wow...this is only slightly terrifying ;-).
Since you're effectively creating a database serialization, why not
simplify the problem by using the concept of primary keys.
So, currently, namevar is built from <name>, could you not instead build
it from multiple values?
In the following example, I'm using the '@' symbol to indicate that
$name/$namevar should be built from an array of values inside the 'foo'
stanza.
foo { @:
+bar => 'baz',
+bar2 => 'baz2',
notakey => 'value'
}
So, $name would now be "baz_baz2" built from the names prepended with a
'+'. I suppose you would probably want to sort the values alphabetically
so that you achieve consistency in your code. Arrays could be handled
through a concatenation of the values or by spawning additional 'foo'
resources.
Does this do what you want? To me it seems to be able to be applied more
generically across all types (including the current ones).
Trevor
On 06/04/2010 06:45 AM, David Schmitt wrote:
> Hi all,
>
> a recurring problem with the namevars are resources that do not have a
> natural unique single-property key. For example, mysql users are defined
> by their username and the host(-pattern) they are connection from.
>
> Traditionally, this was solved by ugly hackery in the type. In the
> windows session at the puppetcamp, Markus and I developed the idea of
> associating a set of patterns/syntaxes with the namevar to automatically
> parse such multi-key titles and automatically put them into proper
> parameters, which can then be validated, munged and used without needing
> to know about the actual syntax elsewhere in the type/provider.
>
> I'll start with an example, of how this could look like:
>
> Puppet::Type.newtype(:mysql_user) do
> @doc = "Manage a mysql database user."
>
> ensurable
>
> newtitle do
> pattern "([...@]+)@([...@]+)", :user, :host
> pattern "([...@]+)", :user
> end
>
> newparam(:user) do
> desc "The username."
> end
>
> newparam(:host) do
> desc "The host, the users connects from. This may be a pattern
> using '%' and '_'."
> defaultto "%"
> end
>
> Patterns would be tried in order and match groups assigned to the
> specified parameters. Having no pattern match woul
>
>
> This could be used in the following ways:
>
> mysql_user {
> "foo": ;
> "f...@%": ; # both 'f...@%'
> "bar": host => "localhost";
> "b...@localhost": ; # both 'b...@localhost'
> }
>
> Mysql_user { host => "webserver" }
> mysql_user { [ "frob", "frub" ]: }
> # expands to 'f...@webserver' and 'f...@webserver'
>
> mysql_user {
> "frob": host => "web1";
> "frob": host => "web2";
> "frob": host => "web3";
> }
>
> The last stanza shows how this can be used to confusing effects. This
> could be mitigated by allowing using arrays in parameters. For example
> creating four users:
>
> mysql_user {
> [ "frob", "frub" ]:
> host => [ "web1", "web2" ]
> }
>
> Here are some illegal constructs:
>
> # Setting a property twice
> mysql_user {
> "foo": user => "bar";
> "f...@%": host => "localhost";
> }
>
> # redefine resources
> mysql_user {
> "frob": ;
> "f...@%": ;
>
> "foo": host => "localhost";
> "f...@localhost": ;
> }
>
> # pattern match fails:
> mysql_user {
> [ "", "@", "foo@", "@localhost", "f...@bar@localhost" ]: ;
> }
>
> For more flexibility when parsing, the list-of-paramnames could be
> replaced by blocks:
>
> pattern "complicated_regexp" do
> # insert disgusting hack here
> end
>
> The block would have to return true or false to accept or reject the title.
>
> By substituting the param names into the patterns, puppet could
> automatically create documentation like this:
>
> Patterns:
> 1) u...@host:
> user must be [...@]+
> host must be [...@]+
> 2) user:
> user must be [...@]+
> user: The username.
> host: The host, the users connects from. This may be a pattern using
> '%' and '_'.
>
> This could be enhanced by specifying additional docstrings with the
> patterns.
>
>
> Of course, this is currently vapour-ware, as it'll need some changes in
> the puppet core to handle the new uniqueness, but I hope to accelerate
> the development by providing a good spec/discussion of how the
> "user-facing" side should look like.
>
> Looking forward to your feedback,
>
>
> Best Regards, David
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: [email protected]
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94
- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkwI364ACgkQyWMIJmxwHpS9eACeMraJMOvRFao9SjbRlGDWfANR
4gkAoMOQf/jj9p9qRQFNlG220kfT1S5x
=rQuK
-----END PGP SIGNATURE-----
--
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.
<<attachment: tvaughan.vcf>>
