On Mar 15, 2012, at 3:06 PM, Ethan Quach wrote: > > > 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.
Destructive and helpful are two different things, I think. While it's helpful for the software to keep your configuration tidy and correct, it *is* destructive in that it removes entries for bootfiles and entire client clauses. It will remain helpful, if the property is set to True. > >> >> 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. 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 > > > -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
