Luke Kanies wrote:
>> I can actually think of *two* new states that one might want: add to
>> fstab
>> and remount an existing mount with new flags, and add to fstab but
>> don't
>> touch an existing mount at all. One might for example want to have
>> a line
>> in fstab for a USB stick, which defaults to mounting read-only, but
>> if the
>> sysadmin wants to she can mount it read-write. If Puppet suddenly
>> remounts
>> it read-only, she might be a bit miffed...
>
> I'm fine with this, I think, although I actually really hate the
> 'enabled => true' stuff in services. I think I've come to the
> conclusion most parameters whose values are only true and false should
> probably be renamed. E.g., services should be enabled/disabled as
> values, although I don't know what the parameter name should be.
> Can't reuse 'ensure', of course.
>
> Maybe we could use ensure, but support multiple values? E.g., you
> could do:
>
> mount { foo:
> ensure => [present, mounted]
> }
>
> Would that be too confusing?
I am often confused by service's ensure/enabled rift (i.e. forget to set
the latter). I think I'd prefer this version.
service:
ensure => [ start_on_runlevel, running ]
ensure => [ no_start, stopped ]
mount:
ensure => present
ensure => [ present, remount_only ]
ensure => [ present, unmounted ]
ensure => [ present, ignore_mount ]
ensure => absent
ensure => [ absent, remount_only ] # doesn't make sense
ensure => [ absent, unmounted ]
ensure => [ absent, ignore_mount ]
Regards, DavidS
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
