Hi, I think I understand -- not adding another control knob.
Even without the extra knob, I think making the criteria and binding precedence *deterministic* and *visible* through the documentation and a published command set falls in the "good" column. Ethan Quach spake thusly, on or about 08/03/09 14:28: > > > Jon Aimone wrote: >> 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. > > Part of the solution to this is the enhancement of the > 'installadm list' command to display the exact criteria currently > in the install service, and which manifest each criteria maps to. > The criteria displayed will be in precedence order. > > Allowing the administrator to explicitly specify a precedence > spot for criteria X is something we're not designing for. (This > would have been the equivalent of the administrator inserting > some arbitrary rule line in the rules file.) The file interface > offered this "flexibility" if you want to call it that, but our > goal here is to have the service coalesce all of the peices of > criteria and present that to the user in an organized way. > > > thanks, > -ethan > >> >> 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 >>>> >>> >> >> _______________________________________________ >> 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/24616fcc/attachment.vcf>
