On Wednesday, March 26, 2014 1:12:33 PM UTC-5, Jesse Hathaway wrote:
>
> In my discussion with @adrienthebo on my pull request:
> https://github.com/puppetlabs/puppet/pull/2309 I raised the question of
> what should be the allowable or suggested values for the ensure property?
>
> My pull request separated out the hold state into a separate property:
>
> before:
>
> package { 'foo':
> ensure => held
> }
>
>
> after:
>
> package { 'foo':
> ensure => '0.4',
> hold => false
> }
>
>
> @adrienthebo suggested I separate out the version instead:
>
> package { 'foo':
> ensure => held,
> version => '0.4',
> }
>
>
> @adrienthebo's suggestion is certianly doable, my question is whether the
> puppet community has come to a consensus on what values the ensure property
> should have?
>
Consensus? Are we talking about the same community?
>
> In general my experience has been that adding additional values to ensure
> for resources makes using a resource less intuitive. For instance I find
> the file resource has a confusing interface because of the way it abuses
> the ensure property:
>
> file {'/foo':
> ensure => file,
> }
>
> file {'/foo':
> ensure => directory,
> }
>
>
> I would rather have explicit resources:
>
> directory {'/foo':
> ensure => present
> }
>
>
> What are the communities thoughts?
>
>
I can only speak for myself, but I don't think there's a clear-cut general
rule for what 'ensure' values should be supported by different resource
types (among those that support such a parameter at all). I think the fact
that most ensurable types have only 'present' and 'absent' as supported
'ensure' values came about more by happenstance than by design. There is at
least one ensurable type -- Service -- that seems reasonably well designed
to me with an entirely different set of ensure values.
The language reference describes 'ensure' as managing "the most fundamental
aspect of the resource on the target system." For many types, simple
presence or absence fits that description, but I don't necessarily call it
abuse to support finer gradations of "present", as File does. On the other
hand, there are types, such as Mount, that do seem to commingle primary and
secondary attributes in their collection of ensure values. That presents
both problems on several levels.
Additionally, there are types for which the standard term 'present' is
distinctly less meaningful than an alternative term. Going back to Mount
for an example, the ensure value 'defined' is much more intuitive to me for
that type than the equivalent 'present'. That would be the case even if
the the mount state (mounted / unmounted) were pulled out of ensure into
its own property, as it probably should be.
With respect to Packages, I am inclined to say that whether a package is
'held' should be managed as a separate property because, as I understand
it, it models a flag that can be twiddled for an installed package. That's
not nearly so fundamental as the package version -- different versions of
the "same" package are in many ways entirely different packages. Perhaps
the package version might be better modeled as a separate attribute, too,
but that's much less clear cut.
File is another interesting study. As I wrote earlier, I disagree that it
is an abuse for that type to support ensure values identifying the type of
File. The File type doe shave its share of problems, but to a large extent
I think they spring from the ubiquity of files in the UNIX design. In the
past I have discussed the possibility of a separate Directory type, I am
somewhat dubious of that idea's practical merit. I would be willing to
entertain the idea of describing the type of file with a separate property,
but even there I'm not persuaded.
Where File does abuse 'ensure', though, is with its provision for using it
to identify symbolic link targets. Thankfully, that usage is now
discouraged.
John
--
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/d4f2b555-ae54-4788-bf1e-56e2452edc67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
