Jack Schwartz wrote: > On 06/08/09 14:37, Frank Ludolph wrote: >> Jack Schwartz wrote: >>> HI Sue and Frank. >>> >>> Susan Sohn wrote: >>>> On 06/05/09 11:40, Jack Schwartz wrote: >>>>> Hi Sue. >>>>> >>>>> On 06/05/09 09:07, Susan Sohn wrote: >>>>>> Jack, >>>>>> >>>>>> On 06/03/09 18:13, 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. >>>>>> >>>>>> Why not just say that the default sysmap manifests will not have >>>>>> criteria? That way, the user could replace the default manifest >>>>>> by simply adding one without criteria and we wouldn't need a >>>>>> special command. It also seems less ambiguous as the distinction >>>>>> between a default and non-default sysmap manifest would be more >>>>>> apparent. >>>>> We discussed this at the Tuesday meeting. Originally, what you >>>>> are suggesting is what I wanted: to have a clear distinction >>>>> between default and non-default manifests. (I wanted to enforce >>>>> this by schema.) But then I thought we all agreed that it would >>>>> be simpler and more straightforward to designate any manifest >>>>> (with or without criteria) as a default manifest. One can easily >>>>> swap a manifest in and out as the default temporarily without >>>>> having to edit or re-edit the manifest, change the service, or do >>>>> anything painful. >>>> >>>> I can see advantages to both sides. It just seems to me like it >>>> might be confusing for users to have the same manifest cause >>>> different behavior, depending on how it is used. I'd suggest that >>>> you ask for Frank's input on this one. >>> As Ethan also pointed out, defining a default sysmap manifest as one >>> without criteria means there can be only one file without criteria. >>> How would we handle the case where someone plops a second >>> criteria-less sysmap manifest onto the system? We would still need >>> a way of saying one of those two files is the default manifest, so a >>> command would still be needed. Alternatively, the default would be >>> given a certain name, and a second file would overwrite the first; >>> suppose the first file is desired again. It still sounds to me like >>> having the ability to install any sysmap manifest (with or without >>> criteria) as a default is preferred. >>> >>> >> Note that if you have two criteria-less sysmap manifests, the one >> designated as default will never be selected because all non-default >> manifests are evaluated first and one with no criteria will always be >> selected before taking the default. >> >> As a rule it would seem that only one criteria-less manifest can be >> active at a time and that it must be the default. If a criteria-less >> manifest is the default and another manifest is made the default the >> original criteria-less default manifest would have to be deactivated. > Yes, a single manifest would be installed as the default. When that > manifest is installed, the previous one would be de-installed. > I didn't phrase it well. The point is that there shouldn't be an active criteria-less manifest that isn't also the default, otherwise it will be the defacto default.
Frank >> >>>>>>> - - - >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
