On Jul 2, 2009, at 5:52 AM, David Schmitt wrote:
>
> 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.
Yeah, that's a big part of the goal.
--
Ah, but I am more perceptive than most of the universe. Especially
the parts of the universe that are vacuum. -- James Alan Gardner
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
