On Wed, Jan 25, 2012 at 6:11 AM, Nick <oinksoc...@letterboxes.org> wrote:
> On 24/01/12 19:53, Nigel Kersten wrote:
>> What if you made two functions:
>>
>> 1. declare_capability("foo")
>>   This would essentially just create an empty resource, Capability[foo]. If
>> multiple modules tried to declare the same capability, it would error, just 
>> like
>> we do today with duplicate resources.
>>
>> 2. require_capability("foo")
>>   This would just declare a requirement relationship to Capability[foo]. If 
>> it
>> couldn't find that resource, compilation would fail.
>>
>>
>> Wouldn't something like this solve the general problem? We don't really want 
>> to
>> just speak about packages, you generally want to be able to express 
>> requirements
>> like:
>>
>> * This module requires a working SSH server
>> * This module requires a MySQL database
>
>
> More generally, I think it'd be nice to have a way to be able to define
> resources, in a way approximately like Puppet already does, but without also
> having to say "and if anyone else tries to define the same name resource in 
> any
> way, fail".
>
> i.e. Say there were two unrelated modules which said slightly different but
> *compatible* things:
>
> Module a:
>
>  file { "/foo/bar":
>   ensure => 'present',
>   owner => 'root',
>   content => "blah blah",
>  }
>
>
> Module b:
>
>  file { "/foo/bar":
>   ensure => 'present',
>   mode => '0774',
>  }
>
>
> Currently Puppet doesn't allow them to co-exist.  It would be nice if instead 
> it
> could be told to check these definitions are consistent, and then enforce the
> union of the two.  The same principle could apply to users, groups, packages,
> and presumably any other resources.

How would this be implemented in a sane way to deal with any
attributes that are hash/array? Merge, merge+unique, fail? What if we
add relationship (require/before) or other meta-parameters to the mix?
If I use the puppet config_version feature to track what resource is
changed by which line of puppet code for auditing purpose, how would I
audit a single attribute that can be due to multiple line of code?
Once I started thinking about define types (which behave like a
resource), it's gets rather complex especially with conditional
branching in the define type.

Don't get me wrong, this clearly would be a useful feature, but I'm
interested only if the rules of how this would behave can be clearly
expressed and understood, otherwise this will be a maze of pain trying
to figure out what part of the code broke something.

Nan

-- 
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.

Reply via email to