On 26/01/12 17:48, jcbollinger wrote:
> In particular, it is useful to recognize that dependencies are not just on a
> particular resource generally -- rather, they are on a particular resource
> having certain specific properties.
Yes.
Also: currently in Puppet one cannot say anything about a resource without a
declaration that you will "manage" it. (Unless perhaps that state happens to be
encapsulated by a Fact, which typically isn't and in many cases couldn't
feasibly be - like the case of file attributes.)
Therefore many "dependencies" are created only because of a need to check some
state of a resource - which one may not want or need to manage.
> Consider, then, a new metaresource type, Constraint. The purpose of the
> Constraint resource type would be to allow multiple unrelated classes to
> collaborate on defining the properties of a single resource, and it would do
> so by allowing classes to limit the values that chosen resource properties
> may have.
>
> At compilation time, Puppet would collect and combine all the constraints on
> any particular resource, and use the results to set unspecified property
> values and validate specified ones. Usage might look something like this:
>
> constraint { 'webserver-httpd_package-present':
> resource => Package['httpd'],
> property => 'ensure',
> forbidden_value => [ 'absent', 'purged' ],
> # also available: allowed_value
> # maybe: default_value
> }
>
> Not only would this nicely meet the needs of different modules to express
> their requirements on shared resources, it would also make it much easier to
> recognize resource conflicts. If Puppet automatically generated empty
> resource definitions to constrain when it discovered constraints on
> otherwise-undefined resources, then that would also overcome the problem of
> deciding where to define particular resources.
>
> I can imagine many -- perhaps most -- resource definitions being replaced or
> supplemented by constraint declarations.
Here's a slightly different angle.
(Note, I'll use capitalisation distinguish between the "resources" that exist
outside Puppet, and the "Resource" instances inside, which model them.)
I think there *is* a case to be made that Puppet needs a new "kind" of Resource
declaration. One which promises never to change the state of anything.
Immutability is, I think, the key to allowing multiple declarations of this sort
co-exist. Resources currently have to uniquely "own" a resource so that they can
safely change it. As I said, one doesn't always need or want that ownership: we
know the kind of baggage it carries.
Ideally we'd be able to separate out the aspects of a Resource which merely
assert what *should* be the case (ensure => present etc.) from those bits which
would then change the state of the resource if it deviates.
For the sake of discussion I'll call that former kind of declaration an
"Assertion".
To briefly address the points from earlier email: Nan asked how would one
address merging, with respect to the following aspects of a Resource?
a) unifying before/requires attributes
b) unifying if/then/else constructs
c) auditing changes back to their source
d) unifying hash/array attributes
Well, when using Resources, yes, these make them very hard to unify in general.
However - although this needs more thought - if we could invent some way to
declare mere Assertions, they might do instead of Resources for many cases, and
it might be possible to unify them more simply, because:
a) Problems related to ordering mostly disappear,
...since nothing is being changed. (Of course, external things which might
change things could be a problem.)
b) If/then/else clauses can still make sense within definitions of custom
Assertions,
...if they can compose only other Assertions, and the conditions don't change.
c) Auditing is not a problem: since nothing is changed, there is nothing to
audit.
d) Hash/array attribute values would need to be resolved on a case-by-case
basis,
...depending on the semantics. When hash and arrays are semantically
representing are sets, this should be a straightforward "and" or "or" operation.
When the order matters, like a search path, or there is no obvious way to unify
two attributes, then this is an unresolvable contradiction and should generate
an error. There may be cases in between.
Possibly this doesn't fit all the use-cases which run into cross-module
dependency problems, but might significantly reduce the need to create the
dependencies in the first place.
Anyway, I need to get back to work, I'll try to say more in a later email.
Cheers,
N
--
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.
