Hi,
you're giving me some interesting ideas.
Note that the constraint approach mainly concerns itself with module
interoperability, and I do believe that the problem you are describing
is orthogonal to that.
I could see something like this take shape if you manage to combine the
autorequire feature with the additional resource generator (one of my
favorite facilities, so cool).
Generating resources already has many of the semantics you sketched:
- it's a noop if the resource in question is puppet managed anyway
- otherwise it models the current state of the entity in question
(barring modifications such as manipulating ensure for purging)
I can picture a metaparameter such as
service { "foo":
autorequire => { Package["foo"] => { ensure => installed } }
}
that would cause the package to be generated, checked for matching
property (is-)values and required by the service resource.
This would suffer the same limitation that constraints will introduce,
unfortunately, which is a certain loss of self-containment. Modules may
not Just Work out of the box anymore, because they depend on the
provisioning of constrained or autorequired resources by means that are
external to the module.
As far as constraints are concerned, those seem to be our best shot at
solving the steaming mess that is defined/ensure_resource, so we may
have to pay this price.
The autorequire metaparameter would be a very powerful way of easing
manifest design, but I'm not quite sure if we can justify paying the
same price.
Or perhaps I'm wrong. That would be cool then :-)
Cheers,
Felix
On 05/06/2014 11:53 AM, Craig Dunn wrote:
>
> This is a lot nicer than the existing workarounds using ensure_resource
> and defined. Previously I was thinking about something along similar
> lines but with slightly different behavior. I was thinking of some
> mechanism whereby if you define a constraint then it will be
> autorequired *if* it is in the catalog, then the provider will use the
> RAL to determine the currently configured state and throw a meaningful
> error if its not configured.
>
> This opens up the posibility of adding a pre-req, but not enforcing that
> the resource is managed through Puppet. Eg: if someone isn't managing a
> package resource in Puppet because it's part of the base OS install,
> then the pre-req will still pass because it exists. If it's a Puppet
> managed resource it will be autorequired and therefore will exist before
> the provider quieres the RAL.
>
> I couldn't find an easy way to do dynamic autorequires this way so gave
> up on it a bit.
>
> I like what you've done here though, I'll have a play with it soon.
>
> Craig
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/5368CD41.4070407%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.
