On Dec 16, 2009, at 11:20 AM, Nigel Kersten <[email protected]> wrote:

> On Wed, Dec 16, 2009 at 9:27 AM, Markus Roberts
> <[email protected]> wrote:
>> On Wed, Dec 16, 2009 at 1:06 AM, Tim Stoop <[email protected]>  
>> wrote:
>>> Honestly, I think it's most obvious if the alias for host does both?
>>> Why would that be a problem? It would simplify the manifest, at  
>>> least.
>>> Changing the name of the parameter would just require extra code.
>>>
>>> I'd prefer to be able to:
>>>
>>> host { "management":
>>>  alias => ["puppet","noc","munin"],
>>> }
>>>
>>> And get the actual IP aliases *and* the resource aliases. Not  
>>> knowing
>>> the technical design, this is how I'd expect it to work. At least in
>>> the case of the host resource.
>>
>> That's kind of been the default assumption, and it sort of makes  
>> sense
>> with aliases of hosts.  But if you think about how this is working
>> inside (one line setting two different things that happen to have the
>> same name and accept similar values) and ask what the "proper"
>> behavior would be in analogous cases, it starts to break down.  You
>> wind up producing some edge cases in which it's not all that obvious
>> how they should be handled:
>>
>> * Suppose you want to use an alias for the puppet resource that's not
>> a valid hostname (e.g. something like "Rack 11 dpr", which is a valid
>> resource alias but not a hostname).  How do you do that?
>> * Similarly, suppose you want to have aliases for the resource to  
>> make
>> your puppet code clearer, but you _don't_ want those name showing up
>> in the hosts file.  How to you do that?
>> * Suppose someone comes up with a resource which has a parameter  
>> which
>> would naturally be named  alias in that context, but only accepts the
>> values "yes", "no", and "local" or some such.  How should that work?
>> * Suppose somebody adds a resource that has a "schedule" parameter
>> (one of the many cron alikes) or something with a "notify"
>> parameter--what's supposed to happen then?
>
> This all seems horrible. I vote to get rid of the name collision, but
> that would be because I've never made use of alias with a host
> resource :)

I agree; these name collisions shouldn't be allowed to exist; this  
sort of special casing makes for confusing inconsistency across types,  
and feels like a slippery slope to begin with. Splitting these two up  
would be my vote.

Cheers,
Bruce
--
Bruce Williams
http://reductivelabs.com

--

You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.


Reply via email to