Luke Kanies wrote:
> 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.
>
That could also tie in formalizing the type/provider interface more,
since the provider would be both the source of the current state and the
mechanism to move to the next state.
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
-~----------~----~----~----~------~----~------~--~---
