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 ?
* old AI image wouldn't work with new manifest - I am not sure if we could
do anything in this point to mitigate this problem.
Appropriate flag day would be sent out to make people aware of this change.
Please let me know what you think.
Thank you,
Jan
