Talk about coincidence. Today I implemented this fragment of a custom
type:
def self.title_patterns
[
[ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ],
[:subinterface_number] ] ],
[ /.*/, [ ] ]
]
end
newparam(:parent_interface) do
desc "The name of the parent interface, automatically parsed from
the title."
newvalues(/^[-_\w\/]+$/)
isnamevar
end
newparam(:subinterface_number) do
desc "The number of this subinterface, automatically parsed from
the title."
newvalues(/^\d+$/)
isnamevar
end
usage:
blah_subinterface {
"ethernet1/2.3": ...
}
leads to this resource_hash:
:parent_interface => 'ethernet1/2',
:subinterface_number => '3',
without any further intervention on my side.
Awesome sauce.
This can be used like this too:
blah_subinterface { "important title":
parent_interface => 'ethernet1/2',
subinterface_number => '3',
...
}
so, there seems nothing in the way of your use-case, no?
Regards, David
On 2014-03-09 21:10, Trevor Vaughan wrote:
Oh, no, this works perfectly. I just *hate* having to stuff all of
that into the name. It makes the hash of options completely
pointless.
I want the name/title to be arbitrary and the rest to "just work".
Unfortunately, I havent found the special sauce for this yet.
Trevor
On Sun, Mar 9, 2014 at 6:29 AM, David Schmitt <da...@dasz.at [4]>
wrote:
On 09.03.2014 03:39, Trevor Vaughan wrote:
In theory a composite namevar could be used if you just specify
the
provider.
For instance, on a Red Hat system:
package { foo: ensure => latest } ==> namevar == foo:yum
And
package { foo: ensure => latest, provider => gem } ==> namevar ==
foo:gem
That said, I never could get composite namevars to work this way.
I
always had to have a unique name which ended up in something
silly like
package { foo_rpm:} or package { foo_gem:} which, while it should
work, is absolutely horrible to read.
That was my understanding how composite namevars should have worked
from the beginning. Sadly, this seems "too complex" or "not useful
enough" to be actually implemented. It would even help for
multi-arch and multi-versions installations: "foo:1.0:i386:yum" vs
"foo:2.0:amd64:yum".
Regards, David
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to puppet-dev+unsubscr...@googlegroups.com [1].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at
[2].
For more options, visit https://groups.google.com/d/optout [3].
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com [5]
-- This account not approved for unencrypted proprietary information
--
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to puppet-dev+unsubscr...@googlegroups.com [6].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com
[7].
For more options, visit https://groups.google.com/d/optout [8].
Links:
------
[1] mailto:puppet-dev%2bunsubscr...@googlegroups.com
[2]
https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at
[3] https://groups.google.com/d/optout
[4] mailto:da...@dasz.at
[5] mailto:tvaug...@onyxpoint.com
[6] mailto:puppet-dev+unsubscr...@googlegroups.com
[7]
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com?utm_medium=email&utm_source=footer
[8] https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/c1984be94fd2d816e19a815490336b58%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
