On 03/15/12 11:35, Jesse Butler wrote:
On Mar 15, 2012, at 2:03 PM, Dave Miner wrote:
On 03/15/12 13:44, Jesse Butler wrote:
On Mar 15, 2012, at 1:39 PM, Ethan Quach wrote:
On 03/15/12 09:25, Dave Miner wrote:
On 03/14/12 22:33, Jesse Butler wrote:
...
Proposed solution
The actions which will cause a local DHCP configuration to be
automatically updated are 'create-service', 'delete-service',
'create-client' and 'delete-client'. Rather than add a new switch to
each of these commands, I'd prefer to add a single boolean SMF
property to the AI service, 'manage-dhcp' or similar. The '-i' and
'-c' options will behave as they are currently do for
'create-service', but will issue a warning if 'manage-dhcp' is not
set to true. For all implicit automated configuration changes, if the
property is true, we will behave as we currently do. If set to false,
then we'll not attempt to update the configuration at all.
I believe that this value should default to false, so that default
behavior out of the box is to not alter any configuration unless
requested to do so.
Jesse, I thought we wanted the default value to be True so that things would be
consistent with default behavior shipped with S11 FCS. Also, update to later
releases won't require action to turn things back to how things behaved before
the update.
We could do that. I think it's best to default to a non-destructive
functionality... but, if maintaining the current behavior is required, we can
certainly default it to True.
Is there a reason behind maintaining the same behavior, other than
compatibility?
The current behavior requires the least work for those who want installadm to manage its
own DHCP resources. Other variations require more effort by the administrator, thus it
seems reasonable to put the extra work there without clear evidence that customers would
tell us to do some DHCP work yet not want us to do it completely. "Make simple
configurations simple", so to speak.
I'm not really basing this on what customers might tell us, but rather I'm
motivated to defaulting to non-destructive behavior. Since the path to enabling
the current behavior would be setting a single property to True, I was thinking
it would be worth the step in favor of not blowing up existing configs by
default.
But it being "destructive" is only in particular scenarios right ... the
scenarios in the filed bugs? By default, it's actually quite helpful to
me that it updates the conf.
If you (and Ethan and John) think we should default to the current behavior,
I'll of course agree to it, but I think we should have a solid reason to
maintain the current behavior.
Barring additional data (which we don't have), the reasoning is the same
as why we decided to default this behavior in the first place. It's
helpful for the simple and easy cases.
-ethan
Did you consider using a marker in the configuration file to record whether
installadm had created it to begin with? That would seem as effective as the
property and perhaps more obvious, though its disadvantage is that it's not
aligned with other ways in which we configure installadm's behavior.
Using a marker doesn't really cover us, I did plan to use one when initially doing
this work, but there are a few scenarios where this doesn't pan out. One example is
when sourcing other files into the main config. We would not find a marked client
entry, so we'd add a new one to the main file, thus overriding a sourced file's
client configuration. Also, we may have someone use the CLI for configuring a
single entry as a template, then c&p'ing others as needed. Not mainline use
cases, but worth consideration.
Jesse
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
