Jesse, I agree with Ethan. We should default to the current behavior. We are giving them the ability to turn it off with the SMF property.
John On Mar 15, 2012, at 10:44 AM, 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? > > Jesse > >> >>> >>> Is there evidence to support that the majority of the cases where DHCP >>> configurations might be manipulated are ones that installadm should not be >>> updating? We generally make defaults conform to the expected common case. >> >> Other than the bugs filed, I don't think we have any more data to tell us >> either way. > >> >> >> -ethan >> >>> >>> Dave >>> _______________________________________________ >>> 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 _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
