Hi Keith. Thanks for your comments. My response is below.
On 06/04/09 08:27, Keith Mitchell wrote: > > > Jack Schwartz wrote: >> Hi everyone. >> >> I have updated the Manifest Inter-File Organization Functional >> Specification per yesterday's meeting discussion. Changes deal with >> how default sysmap manifests are defined/handled. >> >> Link is here: >> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.4.pdf >> >> >> >> With regard to default sysmap manifests, it now states the following: >> >> - - - >> >> A service setup command designates one sysmap manifest to be a >> service's default sysmap manifest. A default sysmap manifest will >> ?match? all systems for which no Sysmap Manifest with explicit >> matching criteria exist, so a default sysmap manifest does not need >> to have criteria. Any criteria in a default sysmap manifest will be >> ignored. >> >> A (non-default) sysmap manifest must have criteria to be useful. >> Non-default sysmap manifests without criteria will be ignored. >> >> - - - >> >> Here's how I see that this will affect at least the AI services and >> webserver teams: >> >> 1) Need a command or way of selecting a new default sysmap manifest. >> >> 2) Define that if there is only one sysmap manifest specified for a >> service, it is the default. >> >> 3) Define how the default file is provided (e.g. by the user, >> template, ???). If a template is not provided as part of AI, need to >> insure that a default sysmap manifest is provided by the user when >> the AI setup command is invoked. >> >> 4) Define warning message behavior (if any) if a sysmap manifest with >> criteria is specified as a default. (Maybe no message?) >> >> 5) Define what to do with the old default sysmap manifest, if a new >> sysmap manifest is installed as the default sysmap manifest. (Keep it >> around, trash it, ??? I suggest keeping it in case the user has >> modified it or created it.) >> >> 6) Define warning message behavior (if any) if a previously-default >> sysmap manifest with no criteria is now no longer a default. (I >> suggest no message.) >> >> 7) I don't suggest an explicit command for uninstalling a default >> sysmap manifest per se. Instead, I suggest that we impose that there >> will always be a default, by implicitly uninstalling the old default >> when installing a new one. >> >> 8) Need a way of listing all sysmap manifests, including the current >> default. >> >> Comments? >> >> Thanks, >> Jack >> > Hi Jack, > > Perhaps you could have three states for a manifest: Installed-active, > Installed-inactive and uninstalled. If a default Sysmap is in place, > and a new one is specified, then the old one gets marked as inactive. > The system still is aware of the old manifest, but won't serve it to > anything. Then, the user could later on, mark the old one as active > (which would mark the new one as inactive at the same time). > "Uninstalling" a manifest would completely remove it from the system. To me, it seems simpler from a user point of view to have two states: installed as the default, or not installed as the default. When one sysmap manifest is installed, the previously-installed one is uninstalled. One can delete a sysmap manifest manually if they don't want to use it. OK. You are defining a third state to be "file-deleted". I hadn't looked at it that way. I think this is just a semantic difference or a difference in perspective, since from either perspective the file can be deleted and the AI could act differently because of that. Or am I missing something? > > I think it might be a good idea to explicitly require that defaults > have no criteria attached, also. Then, any Sysmap that gets installed > with Criteria gets flagged as non-default, and any installed without > criteria gets installed as default. This was discussed earlier this week. We decided that it was simpler to have all sysmap manifests capable of holding criteria. That way, - there is only one schema for default and non-default sysmap manifests, - one can easily specify any sysmap manifest as a default, and then easily change the default to another. Thanks, Jack > > -Keith >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
