[caiman-discuss] Slim Install: First Draft of Target Instantiation Design Spec

[Jan Damborsky]

Hi Sundar,

thank you very much for your feedback. Please see my response in line.

Jan


Sundar Yamunachari wrote:
> jan damborsky wrote:
>> Hi all,
>>
>> preliminary version of design document for Target Instantiation Service
>> which is part of Slim Install project has been posted on
>>
>> http://opensolaris.org/os/project/caiman/files/slim_ti_design-2.pdf
>>
>> It is the first draft with many issues still pending and many design 
>> details
>> to be determined. Any comments, questions, suggestions are appreciated.
>> If possible, please review the document by the COB 9/19/07.
>>
>> Thank you very much,
>> Jan
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>   
> Jan,
>
>    These are my comments. In general you design assumes lot of changes 
> in the orchestrator module. For example Orchestrator doesn't talk 
> about ZFS. Are you planning to update the orchestrator design document 
> with the changes?


You are right that orchestrator would need to be modified, so that 
target instantiation (TI) might work properly. As you are mentioning above,
for Slim, TI will be creating appropriate ZFS structures for handling 
final Solaris instance. Information about ZFS configuration would need to be
provided by orchestrator. For October release, set of attributes 
describing ZFS structures will be simple and will probably only contain 
information
about ZFS root pool and ZFS file systems to be created.

Other modifications which would need to be done to orchestrator relate 
to the intent not to use pfinstall engine for Slim. In Dwarf 
orchestrator prepares
profile file according to information received from GUI and then invokes 
pfinstall in order to carry out set of tasks, which for Slim are to be 
carried out by
TI and transfer module. Since TI will be implemented as shared library 
and will use other approach for describing final target (target will be 
determined
by set of attributes passed as nv list to the TI), orchestrator would 
need to be modified accordingly.

For October release, the information passed from orchestrator to TI will 
be limited and probably hard wired in orchestrator (slice configuration, 
name of ZFS
root pool, set of ZFS file systems to be created - /, /usr, /opt, ...) 
and thus not configurable from GUI.

I am attaching initial version of TI task list with features are 
supposed to be delivered for October release and what might be the 
requirement for March.

As soon as it is determined, how and which information would flow 
between orchestrator and TI, I think I might also update orchestrator 
design document
accordingly.

>
> Section 1: Assumptions
>
>    - The project assumes that ZFS root/boot is available. Can you add 
> the information whether it is already available or when it is expected 
> to be available?

The ZFS structures (root pool and file systems) will be created by TI 
according to information received from orchestrator. In general, I could 
think about
following flow of control:

 * orchestrator receives information about target from target discovery 
service
 * user creates desired target configuration in GUI (limited or not 
supported for October) and passes it back to the orchestrator
 * orchestrator passes this information to the target instantiation 
service which then prepares target accordingly
 * orchestrator invokes transfer module with information about created 
target
 * ...

I will add appropriate information to the document.

>
>    - What is a basic environement? (The second bullet in the assumptions)

I agree this is not quite good wording. I wanted to say that Slim 
doesn't address install within zones or XEN environment. What might be the
more appropriate term here ?

>
>
> Section 2:
>
>    - What is a Manager Module (MM)? Is it same as TI manager? The name 
> sounds too generic. Can you change it to refer to the actual 
> functionality?

Yes, MM is the same as TI manager. I will consolidate it to more 
specific TI manager within document.

>
> Section 5.1.1:
>
>    - Design is spelled as desifn

OK. I have corrected it.

>
> Section 5.2:
>
>    -  Are we planning to support creation of zfs pool across multiple 
> disks during installation?

It is not addressed for October release. I am not sure right now, if we 
would support it for March. If I have understood correctly,
only non-root ZFS pool can be spread across several disks. As far as 
root pool is concerned, I think that support of mirror
configuration might be taken into account.

>    -  What is meant by "It is possible to install on unlabeled disks". 
> How do we determine whether the disk doesn't have a label or it has a 
> label we don't understand?

I was thinking about the case, where sparc is shipped with unlabeled 
disk. In this case it would be necessary to label disk before
read_vtoc()/write_vtoc() interfaces could be used for creating VTOC 
structure.

I will clarify this point in document.

>    -  I don't understand the third bullet "There should be possibility 
> of utilizing unallocated disk space when creating new Solaris 
> partition". Do you mean there will be an interface in MM to specify a 
> special keyword to use all free space?

I meant to say that TI will have to provide following features:
 * creating new Solaris partition within unallocated disk space, when 
there is no Solaris partition available (not for October)
 * using existing Solaris partition

For October release, it is supposed that there would be Solaris 
partition already created before TI is invoked. User will be asked to 
prepare one
before installation is invoked.

It is still not determined for now, how set of attributes describing the 
target partition configuration will look like. Probably the main issue 
here is to
choose the right level of abstraction. For example, the orchestrator 
might pass to TI name of the target device and complete partition table 
to be created.
On the other hand, it might also say to TI something like "Create at 
least 20GB Solaris partition and then let me know where and how big it 
was actually
created". We would need to find appropriate balance here for March.


>    - CLI tools fdisk and and Format can't be used from GUI. Why these 
> CLI tools are mentioned here?

I have meant that TI would use these CLI for creating appropriate 
label/partition table on disks. If I have understood your assertion
correctly, is that mean that if TI is implemented as shared library 
utilized indirectly by GUI via orchestrator, it is not possible
to consume these CLI by TI library ?

>    - pfinstall and ttinstall manages fdisk partitions using the 
> libspmi libraries.

Since pfinstall is not considered to be used for Slim TI would need to 
implement another approach for managing
fdisk partitions.

>    - I am not sure whether it is a good idea to create a label. We may 
> destroy the user data.

Label should only be created when unlabeled disk is recognized (for 
sparc). I will clarify this point.

>    - Are you planning to use fdisk tool to create/modify fdisk table? 
> Why can't use the existing libspmi interfaces?

Originally I was planning to use fdisk utility for this. But this 
assumption might probably change, since
we will probably not deal with fdisk partitions in TI for October 
release and for March it is now discussed
using new interfaces which could be available at that time (for example 
libfdisk library might be one of candidates).

In accordance with the long term goal, we would like to decrease 
utilizing existing spmi interfaces, so that using
of spmi libraries might be completely avoided in future.


>
> Section 5.3.1:
>
>    - Why install needs to create non-root ZFS pool?

This is not requirement for October, since all bits will be installed 
within one root pool.
But based on assumption that root pool can't be striped across several 
slices, it might
be useful to have possibility to define non-root pool which might for 
example utilize
remaining devices not consumed by root pool.

>
> Section 7:
>
>    - If I want to use the existing target (fdisk partition), do have 
> to use ti_target_create() from the orchestrator?

Yes. If fdisk configuration is suitable (that would mean there is 
existing Solaris partition available - this assumption is taken for 
October release)
orchestrator would still need to call ti_target_create() with 
appropriate set of attributes passed as nv list. In this case, 
attributes wouldn't contain
information about fdisk configuration, but would be expected to contain 
information about slice (VTOC) as well as ZFS configuration.

>    - What about deleting a partition?

This feature is not supported for October, but will probably be required 
for March. It is not determined for now, how this information will be passed
from orchestrator to TI.

>
> That is all for now.

Thank you very much.

>
> - Sundar
>
>
>
>
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tasklist.txt
URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20070914/75495219/attachment.txt>