Hi Karen,
On 03/20/09 07:32, Karen Tung wrote: > jan damborsky wrote: >> On 03/19/09 13:32, jan damborsky wrote: >>> Hi Karen, >>> >>> >>> On 03/18/09 19:37, Karen Tung wrote: >>>> jan damborsky wrote: >>>>> >>>>> >>>>> issues to be addressed: >>>>> >>>>> [a] default behavior >>>>> -------------------- >>>>> I think that user expectation would be that if list is empty >>>>> (no package name provided), nothing should be removed. Opposite >>>>> approach would cause problems in situations where user installs >>>>> customized list of packages in which case nothing is to be removed. >>>>> >>>>> The problem is that it is inconsistent behavior with respect >>>>> to the list of packages to be installed - currently, if this >>>>> list is empty, following packages are installed by default >>>>> (as specified in ai_manifest.defval.xml): >>>>> >>>>> SUNWcsd >>>>> SUNWcs >>>>> slim_install >>>>> entire >>>>> >>>>> One possibility is to change this behavior (don't use default >>>>> list of packages) and if no packages are specified for the >>>>> installation, >>>>> nothing will be installed. It might look like it doesn't make too >>>>> much sense to call AI to install nothing, but I think this would >>>>> give us more flexibility. >>>>> >>>>> e.g. let's assume that AI engine will support more than just IPS >>>>> transfer mechanism (like some method of fast provisioning), then >>>>> empty list of packages would just mean that IPS transfer phase >>>>> is not involved. >>>> In DC, the list of packages to be installed is a required element >>>> with no default. The list of packages to be removed is >>>> an optional element. (See DC-manifest.rng). >>>> >>>> To me, I don't think it makes sense to have an empty >>>> list of packages to be installed. I understand the flexibility >>>> argument you are making, but if people are invoking >>>> the installer, it is fair to assume that they want to install >>>> something. In the future, if we want to support more than >>>> IPS, and we don't want to use IPS package list name, we should still >>>> require people to supply some sort of a list of things to >>>> install. So, I think "a list of something" should be a required >>>> element in the AI manifest. For now, you can make it >>>> a list of package names. In the future, that can be >>>> extended easily to support other things. >>>> >>>> The advantage of making it a require element is that >>>> the XML parser will catch the mistake if a required element >>>> is not specified. No special code is needed in the AI engine. >>> >>> I like the approach to let XML validator take care of this. >>> >>> If I understood correctly, then modifications to AI manifest >>> files then would look like: >>> >>> * ai_manifest.defval.xml >>> - no defaults for package lists >>> >>> * ai_manifest.rng >>> - <ai_packages> tag renamed to <ai_install_packages> and >>> made required >>> - new <ai_remove_packages> tag introduced and made optional >>> >>> * default.xml >>> added lists of packages: >>> >>> <ai_install_packages> >>> <package_name> >>> SUNWcsd >>> SUNWcs >>> slim_install >>> entire >>> </package_name> >>> </ai_install_packages> >>> <ai_remove_packages> >>> <package_name> >>> slim_install >>> </package_name> >>> </ai_remove_packages> >>> >>> As far as compatibility is concerned, it would then work in >>> following way: >>> >>> * new AI image wouldn't work with old AI manifest, since new tag >>> <ai_install_packages> would be required. In this situation, validator >>> would let AI engine know that provided manifest is not compatible with >>> new schema. User would be informed on console with appropriate >>> message, >>> for instance: >>> >>> "Invalid or incompatible configuration manifest provided" >>> "Please refer to log files for details" >>> >>> If I understand validator correctly, if we make >>> <ai_install_packages> mandatory, >>> it seems we can't take advantage of creating alias for it in order >>> to allow old >>> manifests to be correctly processed by new AI image - or is there >>> any other possibility >>> we could use ? >> >> Looking at the RelaxNG, it seems we might take advantage of 'choice' >> pattern, >> which allows to specify alternatives in schema - we could do >> something like: >> >> ... >> <choice> >> <oneOrMore> >> <element name="ai_install_packages"> >> <ref name="ai_install_package_contents"/> >> </element> >> </oneOrMore> >> >> <zeroOrMore> >> <element name="ai_packages"> >> <ref name="ai_package_contents"/> >> </element> >> </zeroOrMore> >> </choice> >> ... >> <define name="ai_install_package_contents"> >> <oneOrMore> >> <element name="package_name"> >> <text/> >> </element> >> </oneOrMore> >> </define> >> ... >> <define name="ai_package_contents"> >> <zeroOrMore> >> <element name="package_name"> >> <text/> >> </element> >> </zeroOrMore> >> </define> >> ... >> >> >> Then it would assure that >> >> * after new schema is installed on AI server along with >> latest installadm tools, both old as well as new >> AI manifests will pass validation process and thus can >> be accepted by 'installadm add' command. >> >> * new AI image (with new schema) will be able to accept >> old AI manifests. >> >> That schema defines >> >> * new <ai_install_packages> tag as mandatory >> * that either old or new tag can be used in manifest, >> not both at the same time >> >> Might it sound like a reasonable way to go or is more >> like overkill ? >> >> Jan >> > Hi Jan, > > Your suggested changes above should be able to support > both new and old tag. > > I have a question about the "old tag" allowing empty package list. > What would the behavior of the program be for an empty package list? The current plan is to behave in the same way as if old AI image was used - that means if empty packages list was provided, default list would be picked up from ai_manifest.defval.xml. > I understand we want to support the old tag, but why not > support the old tag, but require at least 1 package name be specified? The reason is that current default AI manifest doesn't contain list of packages, so it wouldn't be functional with new AI image. That said, may be we try to be too much nice in this point. Given the fact that AI is evolving pretty quickly and more fundamental changes are likely to occur, this might not be the on the current list of rules it is reasonable to follow. I am open to suggestions :-) Thank you, Jan
