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 would say the issue is that images are currently tied to services when, in reality, they need to be associated with manifests. Doing so could lead to significant simplification. Having both multiple services and multiple manifests per service is pretty confusing. If we really have to do this we should provide, at a minimum, a guideline for how the user should set things up. For example, "For a release of the AI server, the default AI service is set up to install software for the same release. Add additional manifests to the service to install different software loads for specific (sets of) machines. Create additional AI services to install other software for other releases of OpenSolaris." I probably don't have this exactly right, but you get the idea...
Frank > > 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
