On 03/29/10 04:39 PM, Evan Layton wrote:
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.
See comments in line.
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.
"will be", perhaps?
* 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.
See comments below about reboots...
* 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.
I'm not sure what the "until the System Configuration SMF service is
available" part is supposed to mean. What are you envisioning here?
* 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.
I'm somewhat skeptical that this is the actual requirement, though I
absolutely agree it's a desirable goal. I believe the number of reboots
was specified as a proxy for meeting a performance requirement to fit an
installation/upgrade into a maintenance window more than anything, and
that fast reboot can address a substantial part of that.
* 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.
Whether this will be provided directly as part of AI is something we
need to decide in cooperation with the pkg team, as there are legitimate
concerns about how to manage the transition of content between packaging
systems.
* 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).
I would suggest that this is out of your scope. Not that it's not in
scope for our project as a whole, but I don't think migration owns this
problem - the overall "zones + install" integration effort that is being
organized seems like the better place to me.
* 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
From my point of view, the AI services are really equivalent to a
Jumpstart boot server. The IPS server is more equivalent to the
Jumpstart install server, which is where the installation image lived.
- 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.
add_install_client was *not* always required if DHCP were used with
appropriate configuration. The documentation and so on were never
particularly clear on this point, though.
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.
Then where would it be? I would suggest that the issues of ensuring
that Jumpstart services can be set up on a Solaris Next machine are best
covered as part of your scope.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
