> > 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. 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.
