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
