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 >
