More notes from discussions between Anurag, Alan, Michael, and Renee. And a bonus this time: notes from a follow-up discussion between Liane and Renee. As always, comments/questions welcome.
-renee * Continued discussion of startup behavior reference: "daemon and SMF service" smf-discuss thread, http://www.opensolaris.org/jive/thread.jspa?threadID=85687&tstart=0 Long term, we're very enthusiastic about the profiles idea Liane suggested. Near term, some concerns; big one is simply adding that sort of external dependency so late in the game for phase 1. It also won't completely solve our problem in the near term, as we will still have some configuration data that we need to write out to the filesystem in order to install a location. So we still have the problem of how to insure things happen in the correct sequence on boot. Alan suggested using /etc/svc/volatile, which nwamd can write to before filesystem/usr is online; when ready to install a location, nwamd would write the needed files to /etc/svc/volatile. The net/location service would then have dependencies on both filesystem/usr and the file(s) in /etc/svc/volatile, thus it would only come be started when both conditions were met (nwamd has installed the location, and the filesystem is writable). Its start method would then copy the files out to the correct place. For the case where network/physical:default is enabled instead of nwam, we'll modify its start method to create the files and give it a stop method to remove the files. The one concern with this approach was whether or not the file dependencies in smf are fully implemented yet. Renee will follow up on this with Liane later today. * Extensible properties in locations This is feeling pretty complex; and we don't yet have a clear use case. We do agree that we'll need this, but agreed to defer to post-phase-1. As we don't currently have any consumers, it's not essential immediately; given the work we've done already, though, we're confident this is something we will be able to add--the current design does not block doing so. * nwamcfg syntax nit - use of ncu types and classes: currently, class is required when creating, listing, selecting, or destroying an ncu. The class implies the type, so this (along with the name) is sufficient to uniquely identify an ncu. Would it make more sense to include the type, as well? Or what about adding the flexibility of making the class parameter optional? Conclusion: requiring both type and class, even though type is implied by class, could be confusing ('create ncu ip ip net0' is not especially friendly). We will make the class parameter (mostly) optional, though. If the class is not specified, behavior will be as follows: * on create, the class will be required * on select and destroy, if the name is not unique (there is both a link and ip ncu of the same name), an error will be returned, indicating that the class must be specified to uniquely identify the ncu. * on list, all matching ncus with the given name (at most one link and one ip) will be listed. Anurag will implement these changes and update the docs. - would it be useful to automatically initiate a walkprop on create? If so, should the behavior be different if the -t (use a template) option is used? Conclusion: yes, in all cases, a create will automatically begin a walkprop. - New bug: exit after a syntax error sets the exit status to 1 (failure), regardless of what happens after the syntax error. This matches the behavior of zonecfg; the rationale is that in the case of a script (which is the place where the exit status is mostly likely checked), knowing that an error occurred at any time during processing is important. So we will keep this behavior. - Validation checks: currently, validation fails if a property value that specifies a file path does not map to an existing file. This forces the user to create all files before creating a profile, even if the profile will be exported to a different system. Will remove this check from the validation code. Follow-up notes from my conversation with Liane: One conclusion: enhanced profiles are coming, so it's okay to do a bit of manual stuff now (especially if it means we aren't creating user-visible things that will need to be removed once we have profiles). When we do have enhanced profiles, some of the add-on features we'd like for nwam (extensible locations is a big one) become very easy. Stuff we shouldn't do now: creating service dependencies on network/location for the restarting of services that have configuration that needs to be updated when the location changes. Our current solution has restart_on dependencies for the services that can be restarted; and then the refresh method for network/location explicitly refreshes the services that need to be refreshed. In the enhanced-profile-future, we won't need to do any of this; all we will do is tell smf to apply a profile. So rather than creating dependencies that won't be needed, we could just explicitly restart/refresh as needed in the network/location refresh method. When we do have enhanced profiles, we could simply have nwam manage those (or a subset of those), rather than its own set of locations. Thus a user could create a profile, give nwam some rules about when that profile should be activated, and be done with it. This makes *any* smf property that the user cares about a possible component of the location; we get extensibility for free. We would need to figure out how to pull in the things that aren't smf properties. The fishworks team has done quite a bit of work in this area; while less general-purpose than what we need, it could be a good reference point for us to check out. On the question of file dependencies: they aren't there yet. The presence of the file is checked once during boot, when the restarter is evaluating dependencies for all services. It will also be checked on disable/enable of the service, which gives us a slightly icky but feasible workaround: nwamd could disable/enable the network/location service after writing the config files (after first verifying that the service is already enabled; if for some obscure reason the administrator has disabled it, we shouldn't override that choice).
