Wouldn't this actualy defeat the encapsulation that is provided in the
StreamAPI class? With this change you can reuse the StreamAPI object
for other actions later on too, without loosing the abstraction.
With the chagne you pushed:
diff --git a/lib/domainAPI.py b/lib/domainAPI.py
index 91f2ba3..ddcdc91 100644
--- a/lib/domainAPI.py
+++ b/lib/domainAPI.py
@@ -878,6 +878,14 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
+ def openConsole(self, domname, device, st_obj, flags = 0):
+ try:
+ dom_obj = self.get_domain_by_name(domname)
+ return dom_obj.openConsole(device, st_obj, flags)
+ except libvirt.libvirtError, e:
+ message = e.get_error_message()
+ code = e.get_error_code()
+ raise exception.LibvirtAPI(message, code)
You have to create a new StreamAPI object with DomainAPI.newStream()
and then you have to extract the virStream object from that to pass it
manualy to DomainAPI.openConsole(). IMO this will encourage to use the
virStream object directly without the encapsulation that is provided
by the StreamAPI class.
Peter
Yeath, you are right, we can not cross the encapsulation line.
We have to operate above the abstraction layer.
Your patch is correct definitely.
Guannan Ren
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list