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.
Thanks,
Jack
>
> Jan
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
