Alok,
Responses below.
On 01/14/11 22:52, Alok Aggarwal wrote:
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.
That's a bit ambiguous ;) : Are you saying Correct, that I'm incorrect,
or Correct that final_validation() is a method of Target?
[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?
Yes, absolutely. I would like to see examples of what
TI expects to find in the "desired targets" section of the DOC.
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?
Well - we don't have an agreed new DTD yet ;) but I'll give it a go.
Will TI work (in future) if it finds this in "desired targets"?
<!-- start -->
<target name="desired targets">
<disk>
<disk_name name="c0t0d0" type="ctd" zpool="mypool"/>
<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>
<logical>
<zpool name="mypool" action="create" is_root="True">
<dataset>
<filesystem name="mypool/user1" action="create">
</dataset>
</zpool>
</logical>
</target>
<!-- end -->
- Dermot
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
