Hi Sarah.
Sarah Jelinek wrote:
> 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?
I understand what you are saying, but I'm not convinced that it's worth
doing. Adding an extra layer of indirection complicates the setup for
users, and each criterion is only an XML one-liner. The only time
things would seem to get complicated enough to warrant the extra
complexity would be when the same criteria are repeated for disjoint
ranges, like this (paraphrasing fields, which haven't been defined yet):
<criteria_set>
<IPv4 min=1.0.0.0 max=1.ff.ff.ff>
<IPv4 min=3.0.0.0 max=3.ff.ff.ff>
<IPv4 min=5.0.0.0 max=5.ff.ff.ff>
(etc)
</criteria_set>
Seems like a corner case to me. Am I right, or am I missing something?
If I am right, why bother?
Thanks,
Jack
>
> 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
>>>>>
>>>>
>>>
>>
>
