My commments on the topic of ensure property values are not specific to
any of the particular previous comments, so I am top posting.
The boundary between which part of the resource's life-cycle that should
be described by the ensure parameter, and other parameters/properties is
very blurry. This since *all* of them are used to describe the desired
state of the resource.
It is possible to model this as a structured state machine. The basic
life cycle states are: exists/present, and non-existing/not-present. For
some types it may be more natural to talk about their
existence/non-existence in terms of other words - i.e.
"defined"/"undefined" (but it is basically the same states). When the
resource exists, it can have sub-states, and some of those are in
parallel (it can be big & red, or small & blue), some states are
mutually exclusive, and some states are best modeled as additional sub
states (e.g. exists/configured/active as opposed to
exists/configured/inactive).
While it is fine to use only ensure to describe the desired state out of
all of the available states (as long as they are uniquely identified)
since such a state also specifies all super state (e.g. 'active'
implies, 'configured' and 'exists').
The problem here is one of validation and documentation; how can code
declare the rules, how can they be documented so that it is clear what a
particular value means, and what additional properties then apply.
Secondly, when scalar values are used as value of ensure, this implies a
"type to state coersion", i.e. if a string is given it implies "exists
of given version". This required yet more mental capacity.
While it is easy to read the code; you can guess what "ensure => '4.1'"
means, it is harder to construct given an arbitrary type. Tooling (such
as Geppetto) have a hard time helping a user since the information
regarding what can be used is buried in general Ruby logic. Tools like
Geppetto would benefit greatly by having the ensure parameter be typed
by a state machine.
I got some good things to think about from this topic when we are now
trying to design a better resource type API for Puppet 4.
Back to best practices. I would suggest only using what comes across as
a named state in ensure, and have things like "version" be a separate
property even if it is slightly more to type.
Regards
- henrik
On 2014-28-03 16:01, Jesse Hathaway wrote:
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.
Thanks for pointing out this definition. I think asking whether an
ensure parameter models a fundamental aspect of a resource is a helpful
litmus test for what values an ensure parameter should have for a resource.
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.
I have never liked how the syntax reads, e.g. ensure => '4.1', but I
agree with you that it passes the litmus test of being a fundamental aspect.
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.
My problem with the file type is that though you might be able to access
directories and symbolic links as files in Unix, they model different
abstractions. I think you see evidence of this abstraction in the
separate Unix and Windows cli tools, mkdir, ln, mklink. That is why I
find it a strange mental model that when I need to create a directory or
a symbolic link I need to use the file type.
-Jesse
--
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+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANSNSoV7_9L0O15D15kdMmYkxtpjSYNeXWdcyrkOO6m0jV0kPA%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CANSNSoV7_9L0O15D15kdMmYkxtpjSYNeXWdcyrkOO6m0jV0kPA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lh4705%24ubs%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
