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
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.
- Eventually provide a tool that does a "best effort" translation
from a jumpstart rules file to an AI manifest.
* 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.
* 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. This includes thins like system
configuration settings.
* 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?
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.
