Keith Mitchell wrote: > > > Ethan Quach wrote: >> >> >> Frank Ludolph wrote: >>> Ethan Quach wrote: >>>> >>>> >>>> Frank Ludolph wrote: >>>>> 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. >>>> >>>> That really depends. If we're choosing to say that "criteria-less" >>>> does not mean "default", then the algorithm to choose which one >>>> the default is obviously won't even be looking at criteria; it'd just >>>> be looking for the one marked default. >>>> >>>> >>> No, default is what is selected when everything else has been tried >>> and failed. If there is a criteria-less manifest that is not the >>> default, it will always be selected before the default. >> >> Why would it always be selected before the one marked default? >> Who, in your perspective, is doing the selecting here? >> >> -ethan > Here's my understanding of it. Let's say there are 3 manifests > specified, A, B, and C. "A" has criteria attached to it. "B" has no > criteria attached to it, but is not marked as a default manifest. "C" > also no criteria, but is marked as the "default." > > The client sends its info out to the server, which has to determine > which manifest to return. The server gets the clients specs, and > compares it to manifest A. The specs for the client do not match the > criteria in A, so the server moves to the next manifest. Manifest B > has no criteria specified, so when the server compares the specs of > the client to the empty criteria of B, it finds a match.
Why do you make this assumption? We own this code logic, and if we decide to say that "criteria-less" does not equal "default", why would this have to match here? > The server sends manifest B along to the client. The default manifest, > C, never even was considered, because the server found a manifest with > "matching" criteria before needing to examine the default. In my point of view B and C, as far as criteria matching goes, would not match since they have zero criteria, and hence they don't match anything. The processing code would then fall back to the one explicitly marked as the "default" for this service, which could be A, B, or C. The reasoning behind defining the "default" service to be something determined outside of the manifest content is because the service entity is what owns the specification of which manifest is the default, not the manifests themselves. -ethan > > -Keith >> >>> >>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> caiman-discuss mailing list >>>>> caiman-discuss at opensolaris.org >>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
