Well it appears that caiman-discuss doesn't like my Oracle email address...
Trying again.
-------- Original Message --------
Subject: Second pass on Jumpstart to AI migration requirements.
Date: Mon, 29 Mar 2010 14:39:42 -0600
From: Evan Layton <evan.lay...@oracle.com>
To: caiman-discuss <caiman-discuss at opensolaris.org>
I've updated the requirements with all of the comments received previously. I
would like to get any comments on this second pass by 4/02/2010.
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 profile 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 profile to an AI manifest.
- Provide a tool that does a "best effort" translation from a jumpstart
profile to an AI manifest. This tool we be provided after the
documents steps mentioned above are provided.
* Pre-install tasks
- Most of this functionality will be provided by Derived Profiles.
However there are part of this that can not be provided by derived
profiles and we will need to enable these.
- One example of the kinds of things that we will need to support
is raid configuration. This is something that needs to be complete
before the installation starts so that the install target is
actually available.
Note: the voice of the customer data mentioned this 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
_most_ of this is more of a derived profiles issue and not within scope
for the JS to AI migration project. The requirement listed above is meant
to cover only those items that can not be covered by derived profiles.
* 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 things like system configuration settings and will
be the replacement for sysidcfg type actions until the System
Configuration SMF service is available.
* 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 their own IPS
packages and repos for these types of packages then
include any configuration needed for these in these
packages. This is the direction we would want to move
people that are now just doing tar-balls in finish scripts.
- How do we handle SVR4 packages that can't be migrated
to IPS?
- The thought here is that we provide the ability to specify
SVR4 packages and a location to pull them from in the manifest.
However until this is available in AI it may be necessary to
do this type of installation on first boot.
* Zone configuration.
- meta data about the zones to be created that is then passed to
the zones tools where the zone is actually created.
- Provide a pointer to the archive or list of packages that will
be used to install the zone. This is also passed to the zones
tools (zoneadm etc).
* Server configuration
- Jumpstart servers to AI and IPS server migration.
- AI consolidates the boot server and install server into one server.
- Additionally there is the need to configure the IPS server
- When create client is needed and when it isn't. With Jumpstart
"add_install_client" is always needed. This is not the case for AI.
Note: S10 jumpstart server and OpenSolaris AI server coexistence is
outside the scope of this project as this only covers migration from
Jumpstart to AI not the use of both.
