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.
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.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
