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. > > Frank It took my brain a few minutes to absorb this conversation. If there happens to be a manifest in the system, and it has no criteria attached, then the AI engine would immediately upon examining it find a match. Which means any active manifest in the system with no criteria would end up being chosen the moment it is examined.
This is separate from the behavior that takes place after the AI engine looks at all active manifests and can't find a match. At that point, the AI engine falls back to the "default" manifest. From that perspective, a manifest with no criteria that is defined as "non-default" in some fashion is an error condition, that should be dis-allowed, or at least, warn the user about. -Keith >>>>> >>>>>>>>>> - - - >>>>>>>>>> >>>>>>>>>> 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
