Hi Matt,
I bet you thought I forgot about this :-). My comments...
-One thing I don't see you talk about in this design is the ability to
use an existing pool for installation. It may be out of scope for this
project, but the new schema allows for preserving and use of an existing
pool. Is this something you are considering? In looking at the changes
proposed to liborchestrator it seems as if, with the discovery of pools,
you are, but the steps you list in the AI client changes don't indicate
this.
Page 13, Section 3.2.3.4:
If Data pool, for each target :
If X86 create fdisk partitions only if specified in manifest.
Create VTOC label only if specified in manifest.
Why is this so? The has to specify a vdev to create the pool with right?
And, the vdev's we support are disks, partitions or slices. So, if they
specify a disk, with no partition or slice info, why wouldn't we just
create a default layout? If this is a data pool they must specify at
least a disk in the manifest. The schema doesn't allow for this to not
happen.
-Can you add the details of the libtd changes you are making to this
document? Since we don't have a design for this from the previous work,
it would be good to capture it somewhere.
thanks,
sarah
****
On 07/ 9/10 08:09 AM, Matt Keenan wrote:
Thanks to all for comments to date.
Due to the new AI/DC schema design being implemented before this
project I've reworked the design doc to not include any schema design
and just to refer to the AI/DC schema redesign project instead.
Latest design doc can be viewed at :
http://hub.opensolaris.org/bin/download/Project+caiman/auto_install/ai-multi-design-0.3.pdf
Please have comments back to be by Wednesday 7/14.
cheers
Matt
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
