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? 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? Thanks, --Karen
