Hi Evan, Comments/questions inline...
> On 2/23/10 11:33 AM, Evan Layton wrote: >> I've gone through all of the VOC data and various other sources and >> come up with a list of requirement for the Jumpstart to AI migration >> work. The following cover most of what I believe is needed for this >> work. Please let me know if there are clarifications or additions >> needed >> >> I would like to get any feedback by next Monday March 1st so I can >> then update this and start on the design proposal. >> >> Thanks! >> -evan >> >> > > Based on some comments received off-line I've updated the "Jumpstart > rules to AI manifest translation" to clarify that there will be a set > of documents provided to detail the steps needed to translate from a > jumpstart rules file to an AI manifest and that this set of documents > will be provided before the the translation tools. I also added some > clarification around the "post install tasks" to state that this > includes the replacement for the sysidcfg tasks. > > Thanks, > -evan > > ========================================================= > > Background > ---------- > > for the purposes of migrating customers from current jumpstart > installations > and finish scripts a set of best practices and later a set of tools needs > to be developed. These best practices would give instructions and a set of > tools to allow for a relatively painless migration from jumpstart to AI. > > Requirements > ------------ > > * Jumpstart rules to AI manifest translation. > - Provide a table with comparisons between existing jumpstart rules > and AI manifest entries. > - Provide a set of documents that detail the steps needed to convert > a jumpstart rules file to an AI manifest. > - Provide a tool that does a "best effort" translation from a jumpstart > rules file to an AI manifest. This tool we be provided after the > documents steps mentioned above are provided. > I am a little confused by this requirement. The rules file in jumpstart == AI criteria manifest today, correct? And the jumpstart profile == AI Manifest. So, wouldn't the translation really happen between the jumpstart profile -> AI manifest? Since it appears we are planning to put criteria on the command line and not in a separate manifest, I am not sure there is translation required for rules -> criteria, but maybe there is an opportunity here for something. > * Pre-reboot tasks > - The need here is to allow getting things set up before first reboot > on the newly installed machine that would require a reboot for them > to take effect. For example things like changes to kernel settings > in /etc/system. I am a little unclear what this requirement means. Do you intend that we will provide a best practice on how to do the tasks that have to be done pre-reboot? Or that we provide a utility? Sorry.. this isn't clear. > > * Post install tasks > - We need the ability to provide for similar functionality to the > post-install scripts. This would be used for those tasks that we > would want done on first reboot. So, I assume the recommendation is to have them transfer their scripts to SMF services that run on first reboot? I am wondering how we provide for similar functionality, that is what is the plan? Do we have any sense of the common tasks done in the scripts that we might be able to provide in a set of SMF services so that users wouldn't have to create their own? > - This includes things like system configuration settings and will > be the replacement for sysidcfg type actions. > * Single reboot > - When the installation is completed all tasks needed for the system > to come up as a completed install must be in place. In other words > no second reboot should be needed for anything added through post > install tasks. > > * Installation of third party software or customer packages > - We need to be able to support the customer adding their own packages > during the install. This also ties into the single reboot requirement > and will probably be desirable for the replication work as well. > * A couple of unknowns here: > - We can required users to either provide there own IPS > packages and repos for these types of packages then > include any configuration needed for these in these > packages. > - How do we handle SVR4 packages that can't be migrated > to IPS? The transfer module is being designed to handle SVR4 installations. The AI manifest would have to be modified/designed in a way that this could be specified as well to allow for this. > Note: the voice of the customer data also mentioned the use of pre-install > scripts that were used to determine information about the machine being > installed and from that the image used to do the install. I believe that > this is more of a derived manifest issue and not within scope for the JS > to AI migration project. However, the derived manifest project is one step in the transition from jumpstart to AI, so this should be included in the documentation piece at a minimum, right? So, users know how to transition their begin scripts which do this to using the derived manifest interfaces. thanks, sarah **** > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
