Hi Ginnie.
In the simple case, the user would need to know about only two files. As
you point out, one of them would not be directly handled by the user:
- sysmap manifest: set up by the user (at least for now...), this file
maps the systems to an installation and configuration blueprint. The
sysmap manifest can also contain the installation definition (disk
layout, packages).
- System Configuration Manifest (SC manifest), which is an SMF enhanced
profile set up by a tool and not manually modified by the user. The
user will just add a pointer to it in the sysmap manifest.
The installation definition can be placed into a third file rather than
be embedded in the sysmap manifest, if desired, to handle more complex
setup in a clearer manner. This third file is called an Installation
Manifest.
Could the two files be combined? Yes, but since an external tool will
be creating one of them, it is best to keep them separate.
So for the simplest case, two files. But to make more complex setups
clearer, three files.
Thanks,
Jack
On 06/15/09 13:35, Virginia Wray wrote:
> Hi Jack -
>
> The way I read the functional spec, there are 3+ different files (I'm
> including the sub-schema files that can be called by Install Manifest)
> that the user may have to manage to create an AI manifest
> specification. The System Config Manifest is (or will be) handled by
> SMF, and the others are dealt with manually. I'm having trouble
> envisioning how this creates a compelling user experience. It seems
> overly complex to me. Could you elaborate more on how the user is
> going to interact with these products so that it is easy for them to use?
>
> thx,
> ginnie
>
>
>
>
> On 06/03/09 19:13, Jack Schwartz wrote:
>> Hi everyone.
>>
>> I have updated the Manifest Inter-File Organization Functional
>> Specification per yesterday's meeting discussion. Changes deal with
>> how default sysmap manifests are defined/handled.
>>
>> Link is here:
>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.4.pdf
>>
>> With regard to default sysmap manifests, it now states the following:
>>
>> - - -
>>
>> A service setup command designates one sysmap manifest to be a
>> service's default sysmap manifest. A default sysmap manifest will
>> "match" all systems for which no Sysmap Manifest with explicit
>> matching criteria exist, so a default sysmap manifest does not need
>> to have criteria. Any criteria in a default sysmap manifest will be
>> ignored.
>>
>> A (non-default) sysmap manifest must have criteria to be useful.
>> Non-default sysmap manifests without criteria will be ignored.
>>
>> - - -
>>
>> Here's how I see that this will affect at least the AI services and
>> webserver teams:
>>
>> 1) Need a command or way of selecting a new default sysmap manifest.
>>
>> 2) Define that if there is only one sysmap manifest specified for a
>> service, it is the default.
>>
>> 3) Define how the default file is provided (e.g. by the user,
>> template, ???). If a template is not provided as part of AI, need to
>> insure that a default sysmap manifest is provided by the user when
>> the AI setup command is invoked.
>>
>> 4) Define warning message behavior (if any) if a sysmap manifest with
>> criteria is specified as a default. (Maybe no message?)
>>
>> 5) Define what to do with the old default sysmap manifest, if a new
>> sysmap manifest is installed as the default sysmap manifest. (Keep
>> it around, trash it, ??? I suggest keeping it in case the user has
>> modified it or created it.)
>>
>> 6) Define warning message behavior (if any) if a previously-default
>> sysmap manifest with no criteria is now no longer a default. (I
>> suggest no message.)
>>
>> 7) I don't suggest an explicit command for uninstalling a default
>> sysmap manifest per se. Instead, I suggest that we impose that there
>> will always be a default, by implicitly uninstalling the old default
>> when installing a new one.
>>
>> 8) Need a way of listing all sysmap manifests, including the current
>> default.
>>
>> Comments?
>>
>> Thanks,
>> Jack
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>
>
> --
>
> Ginnie
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090616/f82aeff6/attachment.html>
