On 06/08/09 13:30, Jack Schwartz wrote: > Hi Sue. > > I cornered Frank at the end of your meeting today and discussed your > concern... > > On 06/05/09 14:46, 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. > Frank thought that the ability to install a sysmap manifest with > criteria as a default, and to ignore the criteria in that manifest when > installed as the default, was preferable to mandating that a default > manifest have its criteria removed. > > There were some other outcomes from that meeting as well too... > > 1) From a usability perspective, the simple case is made simpler if > installation manifest contents could just be embedded in the sysmap > manifest. So now installation manifest data can either be in the sysmap > manifest or can be in a separate file pointed to by the sysmap manifest > (as was described before). > > 2) We discussed why there was a need for having multiple services to > serve different clients, and for having multiple manifests within a > service to serve different clients. (At first it seemed redundant to > have both.) Multiple services are needed because services (at least for > now) are bound to images, and images are architecture specific and also > need to be versioned. Within a service, multiple manifests can install > clients differently (but within the same architecture and version). > > I have updated the functional spec with a comment about these items. > > Spec: > http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.6.pdf > > > Delta: > http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec_6_4.pdf >
Jack, Thanks for having the discussion with Frank about ignoring the critera if present in the default manifest. My concern is alleviated, knowing he is ok with it. Sue
