Jack Schwartz wrote:
> 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?
Yes, that's what I am 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?
This is what I was thinking... the sysmap manifests help determine which
service applies to a client. We have multiple 'criteria' that can be
defined to help with this choice. If the user has sysmap manifests
defined, such as one for a range of ip addresses, and one for memory
size. These are defined in two different sysmap manifests. The user sets
up a new service, with a sysmap manifest that points to these other two,
so they don't have to redefine the criteria in another file.
Does this make sense?
thanks,
sarah
****
>
> 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
>>>>
>>>
>>
>
