Constraints beta

[Felix Frank]

Hi,

hoping to reach some of the more prolific module authors via this list,
I'm most pleased to announce the initial release of the constraints
module at

https://forge.puppetlabs.com/ffrank/constraints

I shall try and reach even more authors via the users' list in time, but
if some early adopters could take this for a spin, we may be able to
iron out some quirks even before that.

As for the general support of this idea - there is currently a PR for
puppet proper to add native support for types that pre-validate the
whole catalog. In the meantime, the module does support current versions
back to 2.6.x (using a clean workaround). I don't expect a merge of the
constraint functionality into the core before the Puppet 4 release, but
this ultimately depends on the overall resonance in the community.

TL;DR thanks in advance for using constraints in your modules and
providing feedback.

Cheers,
Felix

[Craig Dunn]

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 puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53656437.1010602%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

--

Enviatics | Automation and configuration management

http://www.enviatics.com | @Enviatics

Puppet Training http://www.enviatics.com/training/

[Felix Frank]

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