Yep.
I'll work on the to/from_xml methods for things like this. Also, I'll
work on fixing any leftover strings of "191" instead of 191.
-Drew
On 3/28/11 6:27 AM, Darren Kenny wrote:
Hi Drew,
I notice that variables like "is_root" are using strings rather than the
expected boolean values. Would it be possible to do the to/from mapping to a
boolean in the from/to_xml methods, so that in Python we can use something like:
if x.is_root:
print "yes"
rather than
if str(x).lower() == "true":
print "yes"
the first just seems more correct to me.
Similarly with values which are expected to be integer values, like the
partition id, why is it "191" rather than the integer equivalent.
As an API consumer these make more sense to be providing or reading values as.
Thanks,
Darren.
On 25/03/2011 22:53, Drew Fisher wrote:
I need to find a few folks willing to look at round 2 of the TI/TD code
review. I'll break this section down into the same 5 chunks Alok did:
a) Target discovery
b) Target Instantiation
c) Target controller API and target validation
d) ctypes interfaces
e) Other
Webrev location:
http://cr.opensolaris.org/~drewfish/cud_ti_2/
Due to Alok's untimely departure, I do not have his existing webrev
directory to do an incremental webrev. If this is problematic, let me
know and I'll work with Glenn to get Alok's machine back so I can try to
spin an incremental webrev.
The major changes between round 1 and round 2 are:
- how disk geometry is figured for non VTOC labeled disks. In debugging
instantiation issues with Karen's installer, we found a pretty large bug
in libdiskmgt (shocking, I know!). Sanjay is still in the process of
examining what is wrong in libdiskmgt and how to correctly fix the issue.
- how slices are created on the disk.
- extremely basic GPT label detection and support. We are *not* yet
ready to handle full creation of a GPT labeled disk with slices, but
discovery now correctly finds them and adds them to the DOC. Consider
GPT support in TI/TD to be read-only.
**NOTE**
I desperately need people to look at the ctypes code. I was unable to
find reviewers for the first pass of the code. I know it's complicated
and I am more than willing to sit on the phone with people to explain it
if need be.
I would love for people to get comments by April 1st. Fool's Day
jokes/comments are acceptable and encouraged.
Thanks,
- Drew, Alok and Jean
(a) usr/src/lib/install_target/td.py
usr/src/lib/install_target/test_td.py
usr/src/lib/install_target/vdevs.py
usr/src/lib/install_target/size.py
usr/src/lib/install_target/test/test_zpool_vdevs.py
b) usr/src/lib/install_target/ti.py
usr/src/lib/install_target/physical.py
usr/src/lib/install_target/logical.py
usr/src/lib/install_target/test/test_target_instantiation.py
usr/src/lib/install_target/test/ti_full.py
c) usr/src/lib/install_target/shadow/*
usr/src/lib/install_target/test/test_shadow_list.py
d) usr/src/lib/install_target/libadm/*
usr/src/lib/install_target/libbe/*
usr/src/lib/install_target/libdevinfo/*
usr/src/lib/install_target/libdiskmgt/*
usr/src/lib/install_target/libnvpair/*
e) Makefiles, DC changes, MP test changes, engine and
errorsvc changes, packaging
_______________________________________________
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
