Hi Alok,
Covers a lot of the details, but I do have some comments ;)
On 13/01/2011 20:32, Alok Aggarwal wrote:
> This email is required reading for: Darren, Dermot,
> Matt, Niall, Karen, Jean and Drew. Optional for others.
>
> The following changes/clarifications are proposed to
> the current TI/TD design.
>
> General flow of an app:
> ----------------------
>
> The app or the target controller will call into TD to do the device
> discovery. TD populates everything it finds in the Target.DISCOVERED
> tree in the DOC.
>
> When the app intends to make changes to the devices/layout
> of those devices, it/target controller will make a copy of
> Target.DISCOVERED and call it Target.DESIRED. The controller will
The target controller won't take a copy of the whole Target.DISCOVERED tree.
When you do a 'select_disk()' call it copies over just the information about
that disk, and constructs a new Target.DESIRED tree with that in it. Similarly,
add_disk() will copy over that disk...
The main reason for this is to avoid the need for TI to have to check, possibly,
lots of disks which haven't been touched at all by the installer, and shouldn't
be.
All that TI should see is the disks that it needs to care about, and it should
leave all other disks untouched.
> then call partition.add_partition/delete_partition,
> slice.add_slice/delete_slice, etc on behalf of the app. These
> calls in turn will trigger validation of the requested change
> using Shadow Lists. If the requested operation yields no
> validation errors, the change is carried through to
> Target.DESIRED. If any validation errors occur, they will
> be stored in the error service and at the same time the change
> will still be carried through to Target.DESIRED. A complete list
> of the calls to make to change Target.DESIRED is below[1].
Is that accurate, since I would imagine that some of the features of the
ShadowList would cause an immediate failure, and thus not be 'carried through to
Target.DESIRED' - specifically the example that Matt mentions about the adding
of a 5th Primary partition on an MBR partition table - that will simply fail
outright (with an exception) when doing the insert in to the ShadowList, won't
it?
>
> The app/target controller decides whether the reported errors are
> "soft" (interim state change is okay) or "hard" (interim state is
> a hard failure). After the app/target controller has made all the
> necessary changes to Target.DESIRED, it calls ti.final_validation()
> which validates Target.DESIRED completely and stores any errors
> thus found in the error service.
>
> The api/target controller has to then go through the process of ensuring
> that the errors in the error service are appropriately addressed
> and final_validation is successful prior to calling TI.
Will final_validation() have a return value that says that it failed, or will
that be determined by asking the errsvc? Seems easy enough for it to at least
return True/False so that you can do:
if not ti.final_validation():
# Check what the problem was
Minor I know, but still worth asking, and I think it would be useful for all the
similar calls for easier coding. Maybe it's already there, but would like to be
sure.
>
> Once Target.DESIRED is fully valid, the app/target controller calls TI
> to lay out the targets as indicated in Target.DESIRED.
>
> Target Validation
> -----------------
> Target Validation will be performed via the use of Shadow Lists
> on the backend. The following is a list of all the validation
> checks that will be made for the respective target entities
> not counting the checks specific for GPT.
>
> Partition
> - Only one Solaris2 partition on a given disk should exist
> - A maximum of 4 primary partitions can be present
> - A maximum of 1 extended partition and at most 32 partitions
> within that (one Solaris2 partition) can be present
> - Partitions should not overlap
> - Partitions should not be too small for a given architecture
> - Solaris2 partition must be <2TB for VTOC
> - FAT32 partition must be <4GB
> - Extended partition must greater than a certain size (to
> account for 63 reserved sectors, etc)
> - A partition must not be in-use for something else (eg: part
> of a zpool)
>
> Slice
> - Number of slices must not exceed MAX_NSLICES
> - Slice number must be MAX_NSLICES-1
> - Slice size must be less than the size of a disk
> - S2 must be the backup slice
> - S1 must be swap slice (is this really even needed?)
> - Slices should not overlap
> - A slice must not be in-use for something else (eg: part of
> a zpool)
>
> Zpool
> - Pool name must be unique
> - Pool should not have vdevs that are part of another pool
> - Pool mountpoint, if specified, should be unique
>
> Size
> ----
>
> TD/TI will internally always operate on sectors (base 2).
> A 'Size' class will be provided to assist in converting
> the size in sectors to bytes/KB/MB/GB/TB.
>
> The classmethods supported by this class are:
>
> def bytes(cls, sectors, cylsize=512)
> def KB(cls, sectors, cylsize=512)
> def MB(cls, sectors, cylsize=512)
> def GB(cls, sectors, cylsize=512)
> def TB(cls, sectors, cylsize=512)
> def sectors(cls, value, units, cylsize=512)
>
> Holey partition/slices
> ----------------------
>
> Holes within the partition/slice table will not be reported
> by TD. The following functions will be provided to allow
> a consumer to get a list of holes within partitions/slices.
>
> def Partition.get_gaps(self, size_units=Target.SIZE_UNITS_GB)
> '''
> Returns a tuple containing HoleyPartition objects corresponding
> to the spaces within partitions. The HoleyPartition objects
> are available to the partition to use when increasing the size.
> The sum of the size of both HoleyPartitions determines the
> maximum additional size this partition can grow by.
> size_units indicates the default human readable size units
> format used in each HoleyPartition object in the returned tuple.
> If HoleyPartitions exist on both sides of the partition
> then the corresponding tuble will be of the form:
> (Before, After)
>
> If no adjacent space exists on a given side of the partition then
> the corresponding tuble will contain the None. (None, After) or
> (Before, None)
>
> If no adjacent space exists on either side of the partition
> then the returned tuple will be (None, None)
> '''
>
> def Slice.get_gaps(self, size_units=Target.SIZE_UNITS_GB)
> '''
> Same as for Partition object
> '''
>
> [1] Target.DESIRED needs to reflect the state of the targets
> in the DOC as they should be laid out by TI. So, if
> modifications to physical and logical devices needs to
> be made, it can be done as follows:
>
> target = Target.DESIRED
> disk = target.get_descendants( .. )
> slice1 = Slice("1")
> slice1.action = "preserve"
Will "preserve" be a constant?
> slice2 = Slice("2")
> slice2.action = "preserve"
> partition1 = Partition("1")
> partition1.action = "create"
> partition1.type = "primary"
> partition1.bootid = 0x80
Similarly w.r.t. constants for these, where possible.
> partition1.size = ..
> partition1.insert_children([slice1, slice2])
> disk.insert_children([partition1])
>
> zpool = Zpool("mypool")
> zpool.action = "create"
>
> vdev = Vdev("vdev")
>
> dataset = Dataset("dataset")
Do Dataset and Vdev really require a name? In the API it would seen unnecessary.
>
> fs = Filesystem("mypool/user1")
Does the name here need to include the pool name? Seems that shouldn't be
necessary.
> fs.action = "create"
Constant?
>
> dataset.insert_children(fs)
> vdev.insert_children(disk)
> zpool.insert_children([vdev, dataset])
>
> Note that the logical stuff needs to change a LOT
> once the target schema changes are made. Also note that
> more examples on do something like above can be found
> in the cud_ti gate under the 'install_target/test' directory.
>
Understood :)
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
