On 08/ 4/10 06:07 PM, Karen Tung wrote:
Hi Jean,
I removed all comments that I have no further responses on.
Other responses inline.
On 08/ 3/10 12:34 PM, jean.mccormack wrote:
* Will progress be reported in the TI and TD checkpoints? If so,
how and when?
For TI probably not, for TD yes. This will be done depending upon the
libdiskmgt interfaces.
i.e. after calls to libtd/libdiskmgt.
Why not for TI? I think that's very useful information, especially
for the case where a large number of targets need to be created.
Current GUI and text installer report progress for TI, even though it is
hard coded.
Sure we can then.
* Is there any facility to help developer debug problems?
Not sure exactly what you're asking. __str__ and __repr__ will be
there but no tool is being planned.
I am not looking for a tool. Perhaps some logging statements with
debug level to
show what's going on, and what targets gets destroyed or created,
which disk/pool
it is doing the discovery on. That way, when people want to find out
why things
don't work, they have a place to look.
Yes there will be logging and some with debug level. Sorry we
misunderstood your comment.
* Section 7.0:
- Is the __init__() call for the Target Discovery checkpoint going to
do anything?
Nothing other than storing any arguments you give it.
The engine is not going to pass any arguments to the checkpoint if
the checkpoint is not expecting any. In fact, when the application
registers the TD checkpoint, and they provide some arguments for it,
but the TD checkpoint is not accepting any arguments, the registration
call will fail. Better to list __init__() with no arguments as an
interface.
I'll __init__ to the doc.
* Section 7.1.2:
- In addition to the type of discovery affecting the amount of time
it takes
to do target discovery, I think discussion how having a large number
disks/pools will affect the discovery time also need to be included.
Yes the large number of disks/pools will effect it. The problem is
that in order to know how many disks/pools there are you need to do
the discovery. So it's a chicken/egg issue.
I understand the chicken and egg issue. I was just thinking whether
it will be
possible/useful to do a quick top level discovery so the performance
estimate will
be more accurate. For example, make a quick call to find out how many
disks are there
in the system, but not go through the details of what's on each disk
until the
actual discovery time.
We need to check out the time it takes to just discover disks. If it
doesn't take a huge amount of time we'll use this in the estimate. Zpool
discovery should be fairly quick. So the answer is probably pending
investigation.
* Section 8.0
- No __init__() for TI checkpoint either?
Nothing other than saving any arguments.
Same as my comment on TD checkpoint's __init__() above. It won't
get any arguments unless it expects some. Since this is an interface
users of TI checkpoint needs to know about, I think __init__() should
appear in the interface table even though it is not going to do anything,
so, users will know to not pass in any arguments.
Will add __init__ to the doc.
- How will all the targets in TI be created? By using the existing
libti.so?
Or create all the targets directly using Python?
If we do use libti.so it will be through ctypes but the plan is to
create all the targets using Python.
OK. In this case, then, I think it would be useful to discuss how you
are
planning to go about creating the targets using Python. Are you going
to call
commands via Python, or are you going to use some Python APIs
from some components? If I remember correctly, ZFS has some Python
interfaces.
Whatever you decide to do, I think it should be documented.
We both think this is an implementation detail and shouldn't be in a
design doc.
* Section 8.2:
- It's not clear to me where these destroy data object and create
data object
live in the DOC tree?
The live in the checkpoint node for TI.
The checkpoint node for TI... When will the checkpoint node for TI be
created, and
who creates that?
The application creates all checkpoint nodes, right?
- Can you give an example on how to specify a "fully qualified
names" of targets
to destroy.
Same question Keith had so obviously we need an example.
Something like : discovered_target.children[4].children[3]
This sounds very error prone. Why not allow people to specify a
tree representation of what they want to destroy, but only destroy
the leaf node of the tree, not the whole tree.
Per Sarah's review this will probably go away so let's drop it.
Jean
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
