hi Renee a few comments below, and some thoughts on possible approaches to GUI representation of the automatic/user modes and switches between.
Renee Danson wrote: > One of my action items for the phase 1 spec was to clarify automatic > NCP/mode behavior. The following text would update the discussion > in section 2.1.3 of the spec > (http://opensolaris.org/os/project/nwam/p1spec/repository/). > > Comments are appreciated! > > -renee > > > With NWAM phase 1, only one NCP is supported; that is, the user cannot > create multiple NCPs, or switch between different NCPs. This limitation > exists for a few reasons: the intention is to implement NCPs as Enhanced > SMF Profiles, and that framework is not yet available in nevada, and will > not be in the NWAM Phase 1 timeframe. Omitting the ability to switch > between and configure different NCPs is also a simplification of the > Phase 1 GUI. > > Because of this limitation, there will be no way to switch between the > Automatic NCP and a user-configured NCP; and there will only be one NCP > available to edit. In order to support the idea of Automatic network > configuration within these restrictions, switching between automatic > and user-configured NCPs will be modeled by a "mode" setting under > which NWAM runs: the service will either be in automatic or > user-configured mode. > > Just to motivate the need for an automatic NCP - the idea is that we'd like to have a fallback "autoconfigure everything" mode, so that users can always switch to it if their custom NCP isn't appropriate, right? > When the NWAM service starts the first time after installation, it will > be in automatic mode, which means that the Automatic NCP will be active. > When a user upgrades from phase 0 to phase 1, I imagine we'll start them in the user-configured mode corresponding to their upgraded phase 0 config? I'm also wondering if it might make sense to just start in user-configured mode in the "fresh install" (or "no previous NWAM configuration") case. In that case, we'll have to walk the datalinks on the system in order to create the automatic and user-configured NCPs (the latter will probably match the automatic for initial installs). Given that, can't we start with the user-configured NCP, and eliminate the need for the initial auto->user switch when editing of the configuration begins? In the upgrade case, this seems like the right behaviour, since we kick off with the upgraded version of the legacy NWAM config, and in the fresh install case, we start off with in effect the same configuration as the automatic NCP, and we can edit it without needing to make the mode switch. The other part of this that I'd like to figure out relating to NCPs is the GUI representation of the automatic/user mode, and switches between. Firstly, I guess we should note the active NCP name, in the same way as we note the active location (see "Network Preferences - Status View") on page 7 of the GUI spec. So above "Location: Automatic", we could have "Network configuration: Automatic/User", depending which is active. In automatic mode, network preferences would not be modifiable, so perhaps the way to handle that would be to prevent modification of the IP address specification associated with the link (see pages 10-12 of the GUI spec). We can't prevent editing of the network preferences entirely, as even in automatic mode, we'll want to be able to change wireless preferences. So the next question is how to represent the switch. I wonder if it'd be feasible to have a button beside the suggested "Network Preferences; User/Automatic" text which is labelled "Switch to Automatic/User Preferences", i.e. switch to whichever mode we're not in? Darren, how do you think we should approach this? The other aspect of this is that if we kick off in automatic mode, the first saving of edited configuration would have additional semantics - it would signify "save and apply these changes" as opposed to just "save these changes", since the first time we save NCP changes, we switch mode. I think this makes a case for starting in editable, user-configured NCP mode also, since if we simply start in editable mode, no mode switch is required when configuration is saved. Does that seem reasonable? > There are two ways to switch from automatic mode to user-configured mode: > nwamd will switch on behalf of the user the first time a user-configured > NCP is saved; or the user may explicitly do so by changing the value of > the nwam service property nwamd/auto_mode to false. In the future, when > multiple NCPs are supported, switching between modes will simply be a > matter of switching from a user-configured NCP to the automatic NCP. > > The first time the user begins editing the NCP (that is, before any user > NCP has been created), the NCP that will be loaded will be the current > version of the automatic NCP. When her changes are saved, they will be > stored as the user NCP. All future NCP editing sessions will begin with > the user NCP, regardless of the current mode (automatic vs. user). > > If nwamd/auto_mode is changed to false before a user NCP is created, the > current version of the automatic NCP will be saved as the user NCP, and > will continue to be used. One thing I'd like to clarify here - the automatic NCP configuration will be reasonably fixed, right (i.e. use DHCP to acquire an address, etc)? The only changes I can think of would be when new network cards are added, is this correct? > However, the user NCP will not be automatically > updated when new physical links are inserted/removed from the system; that > is, the corresponding link and ip NCUs will not be created or deleted > automatically. > Hmm, this doesn't feel right somehow - in the hotplug insertion case, couldn't the corresponding datalink and IP NCUs be added but initialized as disabled (activation == never)? That approach feels more automatic to me. (I definitely agree that in the removal case, it's best not to remove the NCU, as the device may be re-added later, and we'd like to retain configuration preferences). Thanks! Alan
