On Mar 20, 2012, at 10:57 AM, Dave Miner wrote:
> On 03/20/12 10:49, Jesse Butler wrote:
>>
>> Could we continue discussion on this, or could I get a couple of +1's?
>>
>> To summarize, I don't believe there's a way to optionally engage
>> configuration automation without a global AI server property... but I'm
>> open to alternatives. Also, I think we should default to non-destructive
>> behavior out of the box.
>>
>
> The global property is fine.
>
> I continue to believe that the default behavior should be unchanged, so that
> "installadm create-service -i" continues to work without extra effort.
>
> Dave
Ok... I think that Ethan and John also voiced this opinion, so I'll pursue it.
If anyone has any other issues or concerns, please let me know...
Thanks!
Jesse
>
>> I'm fine with changing to suit quorum, I'd just like to have a solid
>> story for ARC'ing this.
>>
>> Thanks
>> Jesse
>>
>> On Mar 15, 2012, at 4:38 PM, Jesse Butler wrote:
>>
>>>
>>> On Mar 15, 2012, at 3:30 PM, Jon Aimone wrote:
>>>
>>>> Hi,
>>>>
>>>> We've already run into some of this in-house. Our labs have started
>>>> deploying the DHCP server that comes with S11 as the "standard," but
>>>> we have many more devices that use DHCP in our labs that are not S11
>>>> clients.
>>>>
>>>> Now we're having to find ways to not accidentally clobber what
>>>> installadm does to the default config file when we make additions for
>>>> other devices.
>>>
>>> That *shouldn't* be an issue, because installadm will only modify
>>> configuration entries for devices you want it to work with (i.e.
>>> explicit mac addrs passed via create-client / delete-client). If there
>>> are other entanglements, please let me know.
>>>
>>>>
>>>> We also have the fact that although we're using DHCP, we do not use
>>>> address pools. All of our systems are statically assigned IP
>>>> addresses, but installadm knows nothing of this. Fortunately the DHCP
>>>> server does not seem to mind us making additional entries for the
>>>> same client ID to statically assign the IP address.
>>>
>>> Right, you can basically have redundant entries... but that's kind of
>>> bogus if for no other reason than tracking/bookkeeping purposes. Plus,
>>> as those get more complex, certain elements will cause an entire
>>> stanza to take priority over other ones, and things can get very gross.
>>>
>>>>
>>>> I agree the simple case should be simple, but not at the expense of
>>>> preventing the more sophisticated configurations.
>>>
>>> Thanks for your view, much appreciated.
>>> /jb
>>>
>>>>
>>>>
>>>> Jesse Butler spoke thusly, on 03/15/12 12:18 PM:
>>>>> Right, but again I'm concerned with blowing up configs. I think if
>>>>> someone has a configuration in place which is intricate and detailed and
>>>>> they aren't even aware that we are modifying their configuration in the
>>>>> background is a bit dangerous, and would likely be difficult to debug. I
>>>>> can imagine an admin getting quite bent out of shape when they finally
>>>>> discover the reason that none of their nodes have DHCP-assigned hostname
>>>>> is because we're trying to help:)
>>>>>
>>>>> So, given the options of a set-and-forget property when actively
>>>>> requesting assistance, versus not blowing up configurations when that
>>>>> behavior was*not* requested, I'd opt for defaulting to the
>>>>> non-destuctive case, and having users explicitly set a property.
>>>>>
>>>>> But, again... quorum will rule. I just might not be happy:)
>>>>>
>>>>> /jb
>>>>
>>>> --
>>>> ~~~~~~~~\o/~~~~~~~~
>>>> Cheers,
>>>> Jon.
>>>> {-%]
>>>> ========
>>>> If you always do what you've always done, you'll always get what you've
>>>> always gotten.
>>>> - Anon.
>>>> --------
>>>> The taxpayer - that's someone who works for the federal government but
>>>> doesn't have to take the civil service examination.
>>>> - Ronald Reagan (February 6, 1911 � June 5, 2004)
>>>> --------
>>>> When someone asks you, "Penny for your thoughts," and you put your two
>>>> cents in, what happens to the other penny?
>>>> - G. Carlin (May 12, 1937 - June 22, 2008)
>>>> <jon_aimone.vcf>_______________________________________________
>>>> caiman-discuss mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>>
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
