> > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANSNSoV7_9L0O15D15kdMmYkxtpjSYNeXWdcyrkOO6m0jV0kPA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
