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

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

Reply via email to