Hi Mike, Thank you for this data! I do have some comments inline.. > 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. > Can you be specific about the criteria you feel are requirements? What I mean by criteria is what things do you believe must be included so that the client can probe and effectively create the correct derived profile? > - 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. > What types of data would drive the rules for the software choices? > - 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. > How would we be able to determine it is a production server? I assume the profile you would derive in this case would have its ips repo set for installation such that there wouldn't be experimental software. Is this what you are thinking?
A few more questions: 1. How easy is it for you to use, and configure your current jumpstart configuration to enable derived profiles? Are the user interfaces easy to use? 2. What do you like about the way it is currently implemented? 3. What don't you like? thanks, sarah **** > > 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 >
