Hi Dermot,
On Fri, 14 Jan 2011, Dermot McCluskey wrote:
Hi Alok,
This is very useful - thanks for writing this up.
I have a few general comments, below.
On 01/13/11 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 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
In practice, I think it will be both the app and the TargetController that
make these calls. The original design was for the app to do everything
through the TargetController, but we then realized this just resulted in
passing target objects around as parameters, rather than using proper object-
oriented programming.
So now, the TargetController sets up the Target.DESIRED tree structure
when a disk is initially selected or another disk is selected or added.
Then the app directly operates on the objects in the Target.DESIRED tree
to make the user's requested changes.
Okay.
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].
Do you also have a list of the errors that can be raised for the
different validation issues? eg I imagine something like:
partition1 = Partition("1")
partition1.action = "create"
partition1.type = "solaris"
partition1.size = ...
try:
disk.insert_children([partition1])
except TOO_MANY_SOLARIS_PARTITIONS_ERROR:
# this is OK while install targets are being configured
pass
except PARTITIONS_TOO_BIG_FOR_DISK_ERROR:
# we can't allow this to stand
display_error(...)
etc
Yep. A list of validation errors will be logged. For example:
if a given partition is invalid in 4 different ways, *all*
4 of those invalidation errors will be logged.
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.
I assumed that final_validation() would be a method of the Target
class, not the ti library? Am I incorrect?
Correct.
[1] Target.DESIRED needs to reflect the state of the targets
in the DOC as they should be laid out by TI. So, if
Right. I think we need a precise definition of what layouts are
acceptable to TI, which I think are a subset of the possible layouts
supported by the DTD. For example, and using XML notation,
*before* the proposed "device referencing" changes to the schema
are enacted, I think your example code below would result in
something like the following objects in the DOC.
Okay, what would help in clarifying what's allowed and what's not.
Sample XMLs or something else?
Will TI run successfully if it finds the following?
<!-- start -->
<target name="desired targets">
<target_device>
<zpool name="mypool" action="create" is_root="True">
<vdev>
<disk>
<disk_name name="c0t0d0" type="ctd"/>
<partition action="use-existing" part_type="191"/>
<partition name="1" action="create" part_type="primary">
<slice action="preserve" name="1"/>
<slice action="preserve" name="2"/>
<size val="..."/>
</partition>
</disk>
</vdev>
<dataset>
<filesystem name="mypool/user1" action="create">
</dataset>
</zpool>
</target_device>
</target>
<!-- end -->
Sorry, I won't be able to answer that, my brain has
already switched over to the new format :) Want to
retry it with new format?
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
