On Sat, Mar 31, 2007 at 03:29:04AM +0800, Thomas Goirand wrote:
> Hi here!
>
> As you may know, we did dtc-xen, that you can find here (and in Debian SID):
>
> http://www.gplhost.com/software-dtc-xen.html
>
> This is a soap server in Python with HTTPS and auth so it's possible to
> control Xen from the outside. In our case, we use it inside our control
> panel to start / shutdown / destroy a VPS.
>
> The problem is that the internals of the xen lib in /usr/lib/python/xen
> changed, and that our software cannot get the information it used to
> fetch. The result is that our control panel cannot tell if a VPS is
> running or not with that newer version of Xen, which is rather bad.
>
> Here is what we used to do:
>
> import xen.xm.main as xenxm
> try:
> if xen_version == 3:
> info = xenxm.server.xend.domain(vpsname)
> return info
> else:
> info = xenxm.server.xend_domain(vpsname)
> return info
>
> The part after the else is for Xen2, of course, and when the method does
> return, the object "info" is serialised to the network, then our nusoap
> php client gets it in a php array/key object. Everything was fine...
> until the release of Xen 3.0.4-1!
>
> The problem is that if I try this:
> print xenxm.server.xend.domain( 'xen01' )
>
> python returns: object has no attribute 'xend'
>
> and if I try this:
> print xenxm.server.xend_domain( 'xen01' )
>
> python returns: object has no attribute 'xend_domain'
>
> I did a diff between xen 3.0.3 and 3.0.4, and it really seems that the
> method changed from xend.domain() back to xend_domain() like how it was
> in xen 2.
>
> So I have 2 questions: 1st, how do I get it running under any conditions
> again, like expected? Am-I missing something obvious here? How do I get
> access to the xen_domain() that still seems to be in the python lib?
>
> 2nd question: how comes the lib in /usr/lib/python/xen is changing from
> 3.0.3 to 3.0.4? Isn't that supposed to be accessed by anybody that wants
> to do some programming with Xen?
Firstly, no, that's not meant to be your programming interface! You are
delving into the internals of xm, the command line interface, and pulling an
internal variable (server) and expecting that to be the thing that you want.
This certainly isn't supported, and it wouldn't be surprising if it broke at
any time.
That said, I don't think that it's the cause of your problem. It sounds to me
like something more fundamental is at fault -- that xenxm.server object that
you are dereferencing is a "magic" object, and so the xend.domain() call is
actually being proxied through as a call to Xend. It's possible that your
server is at fault, rather than your client.
Do you have anything interesting in your server-side logs
(/var/log/xen/xend.log)?
What do you get if you print str(xenxm.server)?
Do you have other calls on xenxm.server that do work? Easy ones would be
xend.node.log() or xend.node.info().
> Please help us, we got 3 new Xen servers in production recently, they
> are up-and-running with Xen 3.0.4, and I really don't want to do some
> ugly code that would fork another process with something like "xm list
> xen01". Also, I'd like to correct our package before Etch is out, and
> it's waiting for this fix before it's uploaded again...
>
> Last: as far as I could see, the Xen API is still not ready, right?
It will be released as Xen-API 1.0 in Xen 3.0.5, which will happen in the next
couple of weeks.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home