Hi Darren,
On Fri, 14 Jan 2011, Darren Kenny wrote:
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.
That is infact ideal, change only what you need to.
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?
I don't believe it should fail, see my response to Matt about
this.
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.
I think it would be useful to add a return value and
relatively easy to do. final_validation() isn't implemented
right now but shouldn't be hard.
[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?
Sure, simple matter of programming :)
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.
Yep.
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.
Both of the above should actually be optional since
dataset/zpool/filesystem explicitly have a 'name'
attribute.
fs.action = "create"
Constant?
Yes.
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 :)
Are there other areas of TI/TD that you feel are underspecified
in addition to what I listed in this email?
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
