Alok, Jean,
You are crediting me with too much subtlety!
I wasn't asking a trick question, I was just trying to
construct what the "desired targets" in the DOC should
roughly look like after the app had run the code fragment
from Alok's original email:
On 01/13/11 20:32, Alok Aggarwal wrote:
[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"
slice2 = Slice("2")
slice2.action = "preserve"
partition1 = Partition("1")
partition1.action = "create"
partition1.type = "primary"
partition1.bootid = 0x80
partition1.size = ..
partition1.insert_children([slice1, slice2])
disk.insert_children([partition1])
zpool = Zpool("mypool")
zpool.action = "create"
vdev = Vdev("vdev")
dataset = Dataset("dataset")
fs = Filesystem("mypool/user1")
fs.action = "create"
dataset.insert_children(fs)
vdev.insert_children(disk)
zpool.insert_children([vdev, dataset])
So, let me turn it around: what should the "desired targets"
looks like after the app runs the code above (or it's equivalent
if there are any API changes resulting from the DTD changes)?
- Dermot
On 01/19/11 00:13, Alok Aggarwal wrote:
On Tue, 18 Jan 2011, jean.mccormack wrote:
On 01/18/11 01:07 PM, Alok Aggarwal wrote:
Hi Dermot,
On Tue, 18 Jan 2011, Dermot McCluskey wrote:
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?
final_validation() is a method of Target, not TI.
[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.
Okay, we'll have something for you as soon as the schema
is agreed upon.
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 -->
Yes, it will. Am I missing a subtlety that you're trying
to point out here?
My question with this manifest is what would you expect it to do? Does
it use the whole disk for the zpool? If so, zpool <disk> will do a whole
disk partition so why are you specifying partition and slice info for
the disk?
That's what Dermot may be alluding to. In other words,
TI will refuse to process the above manifest because
the intent is not clear. The manifest can have only one
of the following specifications:
- Only 'disk' is specified and it has a zpool attribute
- 'disk' has 'partition'/'slice' specified and the zpool
attribute is set on the 'partition'/'slice'.
So, I take back that TI will actually accept the above
manifest as valid. Validation on the above manifest will
need to fail - either at manifest parsing time or during
final_validation.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
