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 Thanks, Jack
