On Jul 1, 2009, at 11:06 AM, Christian Hofstaedtler wrote:
>
> * Luke Kanies <l...@madstop.com> [090701 18:01]:
>>
>> On Jul 1, 2009, at 3:19 AM, David Schmitt wrote:
>>
>>>
>>> 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 ]
>>
>> Any other opinions on this? It has real potential for confusion, but
>> I think we could make it simple enough for the most common cases that
>> people would be fine.
>
> I only can support Davids proposal. It would make at least service
> and mount resources way more descriptive and thus easier to
> understand.
> Maybe also easier to write :-)
>
> Maybe also don't do [ absent, mounted ], but [ configured,
> mounted ], so
> it's even more clear what the author intended. 'present' and
> 'absent' are
> too generic for such combined types.
This brings up a ticket for a refactor I wanted to do ages ago:
http://projects.reductivelabs.com/issues/625
I don't know exactly how these two goals meet, if at all, but it'd be
pretty awesome if someone wanted to tackle the whole problem.
--
It is said that power corrupts, but actually it's more true that power
attracts the corruptible. The sane are usually attracted by other things
than power. -- David Brin
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
