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.
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]
>> 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
