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