On Thu, Oct 22, 2009 at 01:31:22PM -0500, Nicolas Williams wrote: > On Thu, Oct 22, 2009 at 01:40:11PM -0400, Sebastien Roy wrote: > > * Add option to list subcommand, '-x', which includes explanation of > > state > > Why -x and not -v or -xv or anything more in keeping with other Solaris > commands?
As Darren already commented, this usage is in keeping with svcs -x, which is why we chose -x. > > 4. Add '-V' option to nwamcfg's 'get' subcommand > > Default output from the get command is 'propname=propval'. For ease > > of scripting, the -V option outputs the value only. > > Elsewhere we use -H for scripting output. Why not here? mnemonic reasons? This is just one option useful for scripting (and was added now because we had some service method scripts that benefit from it); better scripting output is an RFE. The mnemonic we had in mind here was "Value-only". > > 7. Use 'enabled' property on all locations, not just those that have manual > > activation mode. This means that users can choose to activate any > > location > > at any given time, even if, for example, the location has conditional > > activation specified and its conditions are not currently met. > > > > If a user does activate a location, effectively overriding automatic > > selection by nwamd, that location must be explicitly disabled in order > > to restore automatic selection. > > That's weird. Will automatic selection be able to select a disabled > location? Yes. "Normal" behavior is for nwam to choose what location to enable. Users may create locations with rules about when they should be enabled. But this change makes it possible for the user to explicitly enable a location at any time. The only way to "undo" that action is to either explicitly disable that location, or explicitly enable a different one. NWAM won't override the user's choice. > Why not make it so that enabling a location disables a > special "automatic" location, and that you have to enable that one to > get back to automatic location selction? I'm not sure why you would want that. "automatic location selection" means that nwamd is choosing the best of all available locations, according to specific rules built in to the locations. Trying to map that behavior into some meta-location seems pretty weird to me. > > 10. Remove hosts-file, enable-svcs and disable-svcs properties from Location > > profile > > Use of the hosts-file property, to replace the /etc/hosts file when > > changing location, was not particularly useful, and could lead to > > confusion if some locations specified an alternate file, while others > > did not. > > > > The enable-svcs and disable-svcs properties could lead to similar > > problems, as naming a service in one of these states what the state of > > the service should be when the location is active, but is not explicit > > about what to do when the location is de-activated. The initial state > > is not taken into account, and really can't be, if each location may-- > > but is not required to--specify a state for a given service. > > You could always disable any services which were enabled by enabling a > location, when that location is disabled, even if the next location will > re-enable [some of] them (which would effectively result in a restart). > That would make a lot more sense to me. > > Similarly for hosts file contents. When a location that has a hosts > file is disabled, a hosts file suitable for disconnected operation > should be installed, even if the next location to be enabled will > specify a hosts file (at which point that hosts file gets installed). > > I see nothing really confusing about this... What if the next location doesn't specify a hosts file? It's not a requirement, and *should not* be a requirement. That file "suitable for disconnected operation" is unlikely to be appropriate. The same problem exists, on a larger scale, for the enabled/disabled services list. Not only is it an inappropriate requirement, but it's not at all scalable for each location to specify an enabled/disabled value for every service. That's the only way the enabled/disabled behavior from one location to the next can be completely deterministic. Yes, we could probably design some infrastructure to track all this, and make the behavior deterministic. But that would be diving into the realm of enhanced SMF profiles. The real answer, in my opinion, is for the NWAM team to work with the SMF team to make NWAM locations instances of SMF profiles, and to define, and implement, the features required in SMF to do this. > > 19. Remove support for renaming of NCU objects > > These objects map to physical links and IP interfaces; renaming thus > > involves vanity naming and questions of what exactly is intended. For > > phase 1, renaming of these objects will not be allowed; determining how > > exactly this should work and implementing appropriately remains future > > work. > > > > Renaming of links can be accommodated by disabling the nwam service, > > performing the rename, and then enabling nwam. The new link name will > > be detected and updated in the Automatic NCP; the User NCP will require > > the user to make appropriate updates. > > For links with MAC addresses the renaming of User NCPs could be done > automatically... The problem is, there are a number of incredibly different things that the admin might be trying to accomplish with a link rename. And the rational thing for NWAM to do is very different, depending on which of those things the admin actually wants. Link renaming is still a work in progress, so we felt that for NWAM to jump in with definitive behavior, one way or the other, was premature at this point. -renee
