This is great input, Mike. Thank you for taking the time to provide it. Sue
On 05/07/09 15:50, Mike Gerdts wrote: > I noticed in the AI Client Redesign Meeting Notes[1]: > > Then there was a discussion about Derived Profiles. The outcome was > to gather requirements around the following: > > | - What does deriving mean? That is, what aspects of the profile may > | be derived? What problems are we trying to solve here? > | - Who derives a profile? Some clients or all the clients? > | - Should the client support substitution of certain fields in the > | AI manifest? If yes, what problem will that solve? > | - How does the impact the criteria selection on the AI server? > > Currently I use derived profiles to do the following: > > - Customize partitioning based upon server model, disk size, > memory size, etc. > - Select the appropriate flash archive based on server model > (primarily sun4u vs. sun4v vs i86pc) > > I have a lot of logic in finish scripts (JASS) and third-party system > management tools that does various other things based upon location > (derived from IP address), OS revision, and other criteria that is very > hard or impossible to acquire automatically. Arguably, the bulk of JASS is > legacy baggage with secure by default. > > As I look forward, I would like to derive profiles that: > > - Lays out storage properly. The definition of "properly" will be likely > be dependent on criteria that doesn't work for everyone. That is, at > MyCo we may boot from local disk and want two compressed mirrors. At > YourCo "properly" means to use the lowest numbered LUN presented via > iSCSI from storage array X. > - Select software to install based on somewhat arbitrary rules. That is, > at site X I need the omniback package and site Y I need netbackup. If > it's the primary ldom of a sun4v box, install LDoms Manager 2.4. > - Select repository (or mirror) based on location such that I don't install > across the Atlantic if I have a closer copy. > - Select repository based on location (lab installs experimental bits) > - Require production servers to have packages signed by the OS vendor or by > internal QA. That is, make it impossible to install experimental > third-party software on production. > > > 1. > http://www.opensolaris.org/os/project/caiman/auto_install/AI_mtg/Minutes/ai.client.meeting.txt > > -- > Mike Gerdts > http://mgerdts.blogspot.com/ > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss