Hi Jack,
On 03/20/09 17:25, Jack Schwartz wrote:
> Hi Jan.
>
> On 03/19/09 06:38, 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 ?
> This seems like the right approach if we want to do this. I would
> suggest that the zeroOrMore package names under ai_packages be changed
>
> To be clearer, the above can be condensed to:
>
> <choice>
> <element name="ai_install_packages">
> <oneOrMore>
> <element name="package_name">
> <text/>
> </element>
> </oneOrMore>
> </element>
> <element name="ai_packages">
> <zeroOrMore>
> <element name="package_name">
> <text/>
> </element>
> </zeroOrMore>
> </element>
> </choice>
>
> This way, if <ai_install_packages> is specified, at least one package
> needs to be specified. If <ai_packages> is specified, no packages
> need to be specified. When we're ready to remove ai_packages
> altogether, we can.
This is a good suggestion - thanks !
Looking at the <define name="ai_package_contents"> section,
it contains some additional stuff:
...
<define name="ai_package_contents">
<optional>
<element name="package_name">
<text/>
</element>
</optional>
<optional>
<element name="package_authority">
<text/>
</element>
</optional>
<optional>
<element name="package_version">
<text/>
</element>
</optional>
<optional>
<element name="package_FMRI">
<text/> <!-- http or ftp format -->
</element>
</optional>
</define>
...
Since actually only "package_name" is used for now,
do you think it might be appropriate to get rid of
rest of elements and just go with the implementation
you have suggested ?
Thank you,
Jan
