On 08/30/2012 11:37 PM, Yu Mingfei wrote:
On 31/08/12 03:28, Chris Evich wrote:
Some clarification, because I forgot to put this in libvirt_xml
docstring :( My hope for libvirt_xml module is it should be an
interface between tests and virsh_*() functions. i.e. it should make
writing tests that deal with xml stuff and libvirt, easy to write.
You're exactly right and working along these lines with your new class
(below). But I just wanted to be clear about this module. I'll try
to remember to update docstring.
Some notes/comments below...
On 08/29/2012 10:42 PM, Yu Mingfei wrote:
Signed-off-by: Yu Mingfei<[email protected]>
---
client/virt/libvirt_xml.py | 37
++++++++++++++++++++++++++++++++++++-
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/client/virt/libvirt_xml.py b/client/virt/libvirt_xml.py
index 863022b..c29a307 100644
--- a/client/virt/libvirt_xml.py
+++ b/client/virt/libvirt_xml.py
@@ -11,5 +11,40 @@ class LibvirtXMLVMNameError(LibvirtXMLError):
pass
-class LibvirtXML(xml_utils.XMLBase):
+class LibvirtXML(xml_utils.XMLTreeFile):
Got this in next already, thx.
pass
+
+
+class NetworkXMLError(Exception):
+ pass
Not sure this is needed if...(see below)
Yes, I will remove this class. I have refused by LibvirtXML.:-)
+
+
+class NetworkXML(xml_utils.XMLTreeFile):
My intention ws for LibvirtXML to be a base class in this module.
Then we have a place for general utility methods. Can we make
NetworkXML a subclass of LibvirtXML? Maybe should I rename it to
LibvirtXMLBase()? This way, we don't need NetworkXMLError (unless you
have idea for it), can just use LibvirtXMLError?
Yes, I prefer it to be LibvirtXMLBase(...).:-)
Yep, after reading/thinking about tangchen's thread I think
LibvirtXMLBase is correct. We can use LibvirtXML to hold
libvirt-specific XML (like capabilities).
+ """
+ To configure network xml file.
+ """
+
+ # The root of network xml
+ network_xml = None
If NetworkXML is a subclass of LibvirtXML or xml_utils.XMLTreeFile,
then network_xml is unnecessary. The instance itself will be both a
XML ElementTree _and_ a file object (open on an automatic backup copy
of source).
Right, Since tangchen has a new tree of libvirt_xml.py, I will take a
look and take some comments there.
Yes, definitely. It's best to get the lower-level module / API done
first before writing tests. I know from experience it's MUCH harder to
add/change underlying API after many tests are written. Even simple
think like moving virsh_*() to separate module is a LOT of work :D
+
+ def __init__(self, xml):
+ """
+ Initialize from a string or filename containing Network XML
source.
+
+ param: xml: A filename or string containing Network XML
+ """
+ xml_utils.XMLTreeFile.__init__(self, xml)
+ self.network_xml = self._root
It's not safe to access another class's private namespace like this.
However, it is safe to assume 'self' is already an ElementTree and
file-like object, so self.find() and self.get_root() will all work.
Ok, I know.^
This is partly my fault too, I don't think xml_utils module
documentation is very good. Since this is second (or third) time I have
seen this confusion, there must be real need for better API
documentation. I will put this on my ToDo list for next week.
+
+
+ def general_metadata_config(self, name="", uuid=""):
+ """
+ Edit xml's name and uuid.
+
+ @param name:name of network.
+ @param uuid:uuid of network.
+ """
+ if name:
+ self.network_xml.find('name').text = name
+ if uuid:
+ self.network_xml.find('uuid').text = uuid
How about if this method's code is part of __init__, with name and
uuid as optional parameters?
-- 1.7.1
--
Best Regards
Yu Mingfei
Some more ideas: Method/function to produce network_xml instance from
virsh dump call? What about adding special methods __eq__, __ne__,
__cmp__? Could also hijack __add__ and __sub__ to do some cool things
too (maybe set or unset properties that are == None?). Just some ideas.
Thanks,
Yu
--
Best Regards
Yu Mingfei
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
