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.
* 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.
* 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.
* 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.
* 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.
- 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.
* 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?
- 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.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
