Hi Evan,
One thing which a customer made a strong case for to me at
Community One, was support for splatting a tarball on a system (as it's a
common format for a heterogeneous OS shop). It seems it'd be useful to
have an automated way to do what's suggested in bug 9777 - Need way to
publish a tarball. This may be out of scope but it seems something which
folks would have used a post-install script for and might be easy and
useful to provide.
Thank you,
Clay
On Tue, 23 Feb 2010, 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
>
>
> 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.
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
