Hi Sarah.
Sarah Jelinek wrote:
> Jack Schwartz wrote:
>>>
>>> Section 5.3:
>>>> A Sysmap Manifest may contain zero or more sets of criteria.
>>> So, can a sysmap manifest contain pointers to other criteria
>>> manifests? Or do all criteria in the set have to be specifically be
>>> in the same file?
>> The sysmap manifest contains the sets of criteria, not pointers to
>> them somewhere else. I don't see a point of having a criteria set
>> elsewhere, since they won't be replicated. There should be only one
>> set of criteria mapped to a given install manifest and SC manifest
>> combination. So the set should be defined in the sysmap manifest
>> itself.
>>
>> I can make this clearer by saying "A sysmap manifest contains zero or
>> more sets of criteria," removing the word "may".
>
> Maybe I am thinking about this in a strange way....but I was thinking
> that if users had separate criteria manifests, they wanted to use in
> combination in some way, being able to add a pointer to the criteria
> manifest they wanted to include for a particular service would be
> easier than them having to duplicate it. So, they have a 'store' of
> criteria manifests, which they may use in different combinations for
> different AI install services.
I don't quite understand: maybe my terminology is off. I thought a
"service" was defined by a manifest set, starting with a sysmap manifest
(which defined what was to be installed by its pointers to the install
and SC manifests, and which defined the systems to map it to via the
criteria sets). I'm not counting the AI image which is booted (since
there's talk of decoupling it from the service.)
I thought it would be an error to specify more than one sysmap manifest
("service" to me) per system type. A single sysmap manifest keeps the
mapping of system criteria to system definitions deterministic. It
wouldn't make sense to layer install manifests. I suppose we could have
multiple SC manifests pointed to by a single sysmap manifest. Is this
what you are talking about?
In order to use sysmap manifests in combinations, there would need to be
yet another level of indirection, something binding the more than one
sysmap manifests to a single system type. Also, since a sysmap manifest
points to only two things, what's the point in splitting it?
If you are talking about multiple SC manifests, we could do that.
Already there can be multiple service bundles planned for a single
enhanced SMF profile (which is an SC manifest). We could have more than
one pointed to by a sysmap manifest, and treat all service bundles in
all SC manifests as if they came from one file. Not sure if even SMF
will be able to take two files; if not, some part of AI will have to
combine them.
Thanks,
Jack
> sarah
> ****
>
>>>
>>> Section 6.1:
>>>> Derived Profiles makes configuration of each
>>>> system unique enough on the network to coexist with the other systems.
>>>
>>> It isn't clear to me what this statement means with regard to the
>>> use case it is associated with. Can you clarify?
>> What I meant by this is that derived profiles can dynamically
>> generate parameter values which are unique to each system. I'll
>> clarify in the document.
>>>
>>> Section 6.3:
>>>> This case installs systems all systems with the same disk
>>>> configuration and packages, but
>>>
>>> I think you mean to say 'This case install all systems with the same
>>> disk configuration and packages, but...
>> Thanks. Fixed.
>>>
>>> That's it for now.
>> Thanks so much again for your comments.
>>
>> Jack
>>>
>>> thanks,
>>> sarah
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Hi everyone.
>>>>
>>>> Here is a link to a "functional specification" for solving the XML
>>>> parsing problem of "Current AI manifests are not easy to use." It
>>>> is a rough draft, and I'm posting it to verify that I am on the
>>>> right track.
>>>>
>>>> It deals with XML problem statement 2:
>>>>
>>>> Current AI manifests are not easy to use.
>>>>
>>>> Its scope is inter-file organization of the manifests (naming,
>>>> high-level structure, inter-relatedness), which is quite a limited
>>>> scope for a functional specification. Other redesign tasks (XML and
>>>> others) will tackle the fields inside the manifests.
>>>>
>>>> Please send comments / feedback by lunchtime tomorrow.
>>>>
>>>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.pdf
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Jack
>>>>
>>>> _______________________________________________
>>>> caiman-discuss mailing list
>>>> caiman-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>
>>
>
