On 08/ 2/10 04:39 PM, Karen Tung wrote:
Hi Jean, Dave, and Sanjay,
General Comments:
-----------------------------
* The flow of the document makes it hard for me to follow
the information in the document. In particular:
- Section 2 says the purpose of the document is to describe the
data model for disks, file systems..etc.. But it does not mention
anything about target discovery and target instantiation checkpoints,
and how
they relate to those disks, file systems...etc..
We should add that.
- There's no mention about what programming language will be used. Then,
in section 6.0, it suddenly talks about using inheritances and mixins to
enforce and validate the layout. To somebody that's not familiar
with Python, they would be completely lost as to what those things are.
Also in general, there's no mention about what programming
language is used for implementing the data model, TI and TD.
We'll add the info that the language to be used is Python.
* It will be useful to provide some use cases and/or pseudo-code to
illustrate how some of the existing installers will use the Target
Discovery
and Target Instantiation checkpoints and all the common classes.
We'll add some use cases.
* All the different objects presenting different type of targets are
shown in the diagrams. It will be very useful to have a centralized
section/list/table showing all the different objects.
We'll add interface tables although they may not be accurate.
* 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.
* 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.
Specific Comments:
------------------
* Section 3:
- Is the install engine and/or the checkpoint interfaces also
dependencies?
Yes.
- The libtd.so C library should also be listed as a dependency.
Yes.
* Section 4:
- Section 4 talks about what is supported in Solaris,
and what type of restriction on the number of partitions, slices,
GPT is supported...etc.. Is that something you just happened to know?
Is there any reference documents that you retrieve these information
from and can list for somebody who wants to know more about the
how and why Solaris provides those features and restrictions?
We just knew them. If anyone knows of such a reference tell us and we'll
put a pointer to it.
* 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.
- General question about the TD checkpoint. If the TD checkpoint is
called twice in the same process. Will it create 2 tgt trees?
Will it discovered that the tgt tree is already there and just
return? Will
it remove the existing tgt tree and do the discovery again? I am
thinking
of the situation where the GUI installer calls target discovery,
and it returns one layout. Then, outside of the installer,
I did some changes to the system, and then, I go back to the
layout screen in the GUI installer, and if the GUI installer call
TD again, whether changes I just made will show up or not?
The architecture specifies that target discovery will go to a "well
known" location so
we are constrained to putting the tgt tree in 1 place. So if it is
called twice we will blow over the top
of the currently existing discovered_target tree.
* 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.
* Section 7.2:
- Why is the type of discovery to do need to be stored in the DOC?
Can't the application specify that as an argument when it register
the TD checkpoint?
Yes. We'll consider this. Seems like a good idea.
* Section 8.0
- No __init__() for TI checkpoint either?
Nothing other than saving any arguments.
- General comment about this section is that it will be very useful to
include some basic example on how I would go about creating some targets
such as: install target, swap zvol, ram disk
We can include some examples.
- 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.
* Section 8.1.1:
- If I specify dry_run flag, the document said no changes to the
target will
be performed. Will the function just return or it will actually do
some calculation and log or return that information some how?
It will do the calculations and log the commands it would have run along
with their arguments.
* Section 8.1.3:
- Since the TI checkpoint makes modification to the system, it will be
useful
to provide more details on exactly when the cancel flag will be checked?
The cancel flag will be checked after each "creation" of a target. i.e.
after fdisk, after zpool create ....
Also, spell out explicitly that the target will be in an indeterminate
state after cancel().
Sure.
* 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.
Since everything in DOC has a name, what names
will these objects have?
destroy and create
- 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]
* Section 8.3:
- It will be useful to discuss exactly what will happen when there's
an error. If I specified for both things to destroy and create, and
the destroy failed, will you try to create?
Depends upon how the destroy failed. If it fails because we're rerunning the
checkpoint and the target has already been destroyed, then that isn't an
error and the
create will occur. Otherwise we don't do the create.
What about if multiple
targets needs to be created and creating the first one failed, will you
return immediately or try to create the subsequent ones?
Return immediately after the first failure.
We'll add wording to make this clear.
Jean & Dave
Thanks,
--Karen
On 07/27/10 12:34, jean.mccormack wrote:
Please review the design doc for the Common Object classes/TI/TD
design located at:
http://hub.opensolaris.org/bin/view/Project+caiman/CUE_docs
We'd like to get comments by COB on Tuesday August 3rd.
Thanks,
Jean, Dave, & Sanjay
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
