Hi, I believe having an explicit binding precedence, whether it's predefined or something an administrator can set, helps keep life simple. This was one of the first questions that came up from others in my group when we started testing 09.06 builds on SPARC systems.
Thanx! I like this. Sundar Yamunachari spake thusly, on or about 08/03/09 13:53: > Jon, > > Thanks for the comments. > > Jon Aimone wrote: >> Hi, >> >> First, I like the idea of separating the criteria from the manifest >> itself. >> >> I have a question about binding precedence. Would a manifest named in >> create-client bind tighter that a manifest named in create-service or >> add-manifest? > Yes. create-client associates a specific manifest to the client. So it > has higher precedence. >> >> Thinking about the add-manifest command, the subject of criteria >> collisions and binding precedence remains ambiguous. It would be easy >> to specify multiple manifests using difference criteria that would >> each be appropriate for a given system. Which manifest would be used? > The client specific manifest comes first. The server may choose a > manifest which matches more criteria of the client. We have to define > exact order of precedence to avoid collisions. >> >> Also, putting the criteria into a finite set of name-value pairs >> known to the command also seems to impose some restrictions or at >> least difficulty in adding to the potential criteria for selecting >> the target system... or is the intent to limit the potential criteria >> to always be network, memory, architecture and IP addresses? > No. The definition of the interface is only an example to show that > the effectiveness of the proposal. We could define the interface such > that it could load the criteria from a file. >> >> I feel the number of systems involved in the scenarios is too small. >> In-house we have labs with not tens but hundreds of systems on which >> we currently deploy OpenSolaris where most (95%) of the systems get >> one of two "default" manifests selected by architecture and limited >> to an IPv4 range. This set could be better utilized if the selection >> criteria could be extended to discern platform, SAN (including >> iSCSI), storage, and NIC present on the target system when choosing >> from a set of about ten manifests. > The initial set of criteria is just basic characteristics. It was > always planned that it will be extensible and may be add user defined > criteria in the future. > > Thanks, > Sundar >> >> I don't know about other labs, but I've never written a manifest [or >> old jumpstrat profile] for memory size. I've always used memory size >> to choose appropriately sized disks and compute disk slice sizes. >> >> >> Sundar Yamunachari spake thusly, on or about 07/31/09 18:06: >>> Hi, >>> >>> The proposal to simplify AI manifest by removing criteria manifest >>> is updated and available at >>> http://www.opensolaris.org/os/project/caiman/auto_install/manifest_simplification_proposal_v2. >>> >>> The document has more information and user scenarios. Please review >>> the proposal and provide your feedback. >>> >>> Thanks, >>> Sundar >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > -- ~~~\0/~~~~ Cheers, Jon. {-%] ======== If you always do what you've always done, you'll always get what you've always gotten. - Anon. -------- When someone asks you, "Penny for your thoughts," and you put your two cents in, what happens to the other penny? - G. Carlin (May 12, 1937 - June 22, 2008) -------------- next part -------------- A non-text attachment was scrubbed... Name: Jon_Aimone.vcf Type: text/x-vcard Size: 305 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090803/755e772a/attachment.vcf>
