On Mon, Feb 14, 2011 at 8:56 AM, Dan Bode <d...@puppetlabs.com> wrote:
>
>
> On Mon, Feb 14, 2011 at 6:49 AM, Nigel Kersten <ni...@puppetlabs.com>wrote:
>
>> On Sun, Feb 13, 2011 at 9:59 PM, Dan Bode <d...@puppetlabs.com> wrote:
>>
>>>
>>> We have only been teaching <| |> in the puppetmaster training as a way to
>>> realize virtual resources. We do not teach that it is possible to override
>>> attributes with this syntax as well: <| |> {} (at least in part b/c the
>>> implications/non-determinism terrify me) , and do not teach that it actually
>>> effects all resources.
>>>
>>
>> Why is using collections to override attributes non-deterministic compared
>> to class inheritance doing the same thing?
>>
>
> With the below example, the evaluation order of the overrides determines
> the final value.
>
> notify { 'foo':
> message => 'bar',
> }
>
> Notify<| |> {
> message => 'bazz'
> }
> Notify<| |> {
> message => 'baz'
> }
>
> # try this example and swap the overrides
>
> With class inheritance, any attempt to override the same attribute twice
> fails:
>
> class a {
> notify { 'foo':
> message => 'a',
> }
> }
> class c inherits a {
> Notify['foo'] {message => 'c'}
> }
> class b inherits a {
> Notify['foo'] {message => 'b'}
> }
> include a,c,b
>
> :!puppet apply /tmp/foo2.pp
> Parameter 'message' is already set on Notify[foo] by
> #<Puppet::Resource::Type:0xb7a430c8> at /tmp/foo2.pp:9; cannot redefine at
> /tmp/foo2.pp:12 on node mypuppetmaster.localdomain
>
Hmm. So it's order-dependent because you can do it more than once, unlike
class inheritance. Overriding the same attribute more than once via
collection feels like a code smell to me.
The common example from class is something like:
>>>
>>> class db::users {
>>> user { ['alice', 'bob']:
>>> ensure => present,
>>> gid => 'dbadmin',
>>> }
>>> }
>>>
>>> class app::users {
>>> user { ['charlie', 'bob']:
>>> ensure => present,
>>> gid => 'webadmin',
>>> }
>>> }
>>>
>>>
>>> class app {
>>> User<| gid == 'webadmin' |>
>>> ...
>>> }
>>>
>>> class db {
>>> User<| gid == 'dbadmin' |>
>>> ...
>>> }
>>>
>>> so that a machine can safely be a webserver and db server without
>>> conflict.
>>>
>>
>>
>> Why is this preferred over the realize() function? I consider the realize
>> function much simpler to teach and understand for this class of problem.
>>
>
> The realize function requires that we have to know all of the names of the
> resources that we are realizing. Consider the example where each group of
> users has 10 members, the above syntax is way easier to manage than:
>
> realize(User[1], User[2], .... User[10])
>
>
ah, but your collection syntax requires that you have to know the gid of the
resources you are realizing :)
There are certainly cases where the collection syntax is easier, but I feel
that the vast majority of virtual resource realizations I see in the wild
are for one or two resources where the name is known.
--
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.
