On 2/24/10 7:29 AM, Jan Damborsky wrote:
> Hi Evan,
>
> I am not sure if this is in scope of this effort, but one area which
> does not seem to be covered here is how things will change with respect
> to install server configuration.

I think this is something that is not really in scope for this project
and is something that would normally be done on the system after initial
install of the system.

However I don't think what has been stated in these requirements would
preclude adding the installation of the AI packages and configuration
of these as part of an initial install.

> To ease the transition, maybe we could compare common scenarios -
> how configuration is done in case of jumpstart (by means of
> setup_install_server & add_install_client) and then show how to set
> up AI server for the same scenario by means of installadm(1M) tools.

I don't think this would really be different from any other package
installation. The installation would include the creation of the
smf service that runs on first reboot which would do the expected
installadm tasks. Based on this it should be possible to show this
as an example.

-evan

>
> Jan
>
>
> On 02/23/10 07:33 PM, 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
>

Reply via email to