David Bustos writes: > Quoth James Carlson on Thu, Jan 22, 2009 at 09:10:52AM -0500: > > David Bustos writes: > > > uncommitted changes. Modify the boot process to re-apply the > > > generic_*.xml and platform_*.xml profiles through this interface > > > after each upgrade (and perhaps more frequently). This should > > > obviate many uses of the /var/svc/profile/upgrade file. > > > > The "perhaps more frequently" phrase is likely to attract unwanted > > attention. Is there some future direction hidden under this? > > Re-applying the profiles on every boot is simpler to implement, and > I don't foresee it causing any problems. So unless it does cause > problems, that's what we'll do. Do you think this needs to be spelled > out?
I would. Having "either-or" sorts of items in a spec often causes ARC reviewers to ask funny questions. > > - If I delete a customization, what do I end up with? Do I get the > > value that is set by a profile or do I revert all the way back to > > the manifest value? > > > > My naive assumption is that this appears to be layered -- admin > > changes build on the profile settings, which build on the > > manifest, so deleting the administrative change should go back to > > the profile value -- but I suspect that's not actually true, and > > that only one layer separation (default and current) is kept. > > Your naive assumption is what we're intending. Though I should specify > that in this phase only the generic.xml and platform.xml will be placed > in their own layer -- profiles applied by a user with svccfg apply will > be considered customizations (equivalent to svccfg setprop's). OK; that's good to hear. It'd be confusing otherwise. > > - Why have "cust" as a special case? It seems to me that users will > > want to be able to list properties that were set not just by > > direct administrative action, but also by applied profiles and by > > named manifests. Why not allow listing by attribution? > > Only timing. We've decided to defer that to a later phase. Would it make sense to plan for that now? Instead of "listcust," maybe something like an "-a <attributed-to>" option for the existing listprop? (One could imagine a number of ways to filter properties -- "show me the ones where the user overrode a profile setting", or "show me the manifest settings hidden by either a profile or a user value.") I guess I don't care too much about this, but the "cust" part seems a little narrow and might not age well. > > > - Enhance SCF to be able to record the association between service > > > manifests and the services and instances they deliver. When service > > > manifests in /var/svc/manifest are changed, use the information to > > > remove services and instances absent from the new versions. > > > > That sounds problematic for upgrades. > > > > If I refactor a service from one manifest to another (because, for > > example, I'm reworking the packaging for a group of related services), > > then this either changes from a simple upgrade (with no loss of > > information) into a delete+add, and the user loses his customization, > > or into a confusing addition of the same service from a different > > manifest followed by a delete that might wipe the service out > > completely. > > The implied infrastructure in svc.configd makes this easy to fix: When > a service or instance is removed from the repository because it is > removed from a manifest, we can discard the defaults the old manifest > delivered, but retain customizations made by the administrator. Then, > if another manifest delivers the service, we can automatically apply the > old customizations to the new service. Just like the described behavior > for when the generic.xml and platform.xml profiles prescribe properties > for services or instances which don't exist. That'd work quite nicely for that case, and much simpler than what I was picturing. > Of course, if such customizations live too long, their re-appearance > could be surprising. I suspect it would be sufficient to include such > customizations in svccfg listcust output, probably flagged somehow. > Does that sound reasonable? Yes. I'm not sure what the default behavior should be for a system upgrade. On the one hand, it might make sense to keep the customization around in case there's some follow-up work required (e.g., reinstalling some third-party software). On the other hand, these things could end up being creeping crud. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
