This page is for planning and collaborating on an effort to modify Xend to use XML-RPC as a transport layer replacing the current HTTP based protocol, simplifying the Xend codebase significantly.
Plan
- Make xm use XML-RPC
- Introduce an XML-RPC Server into Xend that can listen on a domain socket (or tcp socket)
Expose XendDomain, XendDomainInfo, XendNode, and XendDmesg functions though that interface
Port XendClient to use the XML-RPC interface
- Validate with xm-test and submit for include into Xen
- Deprecate S-Expression/HTTP protocol
- Standardize a set of management calls
- Put a version number on and declare backwards/forwards compatibility.
Remove XendClient and plumb xm to use XML-RPC directly.
- Rewrite portions of xm to simplify internationalization
- Should xm be autodiscovering
- Remove S-Expression/HTTP protocol
- Change internal configuration representations to XML
- Look for opportunities to simplify Xend further
Other Items
- Support a configuration file in xm
- I know we had more items than this...
- Provide web-management interface that uses javascript XML-RPC library?
Schedule
Item |
Targetted Release |
Owner |
Status |
1 |
3.0.2 |
Anthony |
Validating with xm-test |
2 |
3.0.3 |
TBD |
N/A |
3 |
3.0.4 |
TBD |
N/A |
Transition Plan
To support existing users of the Xend S-Expression/HTTP transport, I think it's only appropriate to give at least a single release time frame for deprecation. A good migration strategy would be to begin porting your applications to libvir since it will follow all the Xend changes as they happen. It currently supports the S-Expression/HTTP protocol so you should not lose any function in the transition.
If there is substantial push-back about removing support for S-Expression/HTTP, we can perhaps leave it in for a release more. However, I don't expect this to happen.
Offline Domains
When we get to stage 3, and switch configurations to XML (this isn't set in stone so alternative suggestions are welcome), it then becomes more practical to central configuration storage. We can then have Xend expose domain configurations as virtual machines. The immediate implications for xm aren't that exciting, but for other consumers, it certainly is. Imagine a gnome applet that drops a list of domains (online and offline) and let's you easily start up a domain with a single click. Suspended domains are just a special instance of an offline domain too.
Exceptions
XML-RPC supports exceptions in the protocol. When we standardize the API, we'll want to introduce a set of standard exceptions for common errors (Domain does not exist, for instance). Of course, it would be nice to also introduce an InternalError exception that serializes any unhandled exceptions within Xend and passes through a stack trace. This would make debugging Xend significantly easier.
Call for Help
The more people that are involved in this transition the better. Just providing feedback is a good start. Signing up for some of the future effort would be even better.
Regressions Results
For x86_32:
Xm-test execution summary:
PASS: 99
FAIL: 4
XPASS: 0
XFAIL: 3
Details:
FAIL: 04_block-destroy_nonattached_neg
xm block-detach returned a stack dump, expected nice error message
XFAIL: 02_network_local_ping_pos
ping loopback failed for size 65507. ping eth0 failed for size 65507.
XFAIL: 05_network_dom0_ping_pos
Ping to dom0 failed for size 1 48 64 512 1440 1500 1505 4096 4192 32767 65507.
XFAIL: 11_network_domU_ping_pos
Ping failed for size 32767 65507.
Code
News
02/07/2006 - xm-test is now passing 100% (ignoring the stack dump one as that is preferred behavior now). Will post code shortly.
02/03/2006 - I've made much better progress than I expected with xm-test. I'm already at an ~80% pass rate and expect to be at a 90% very soon. I've implemented full support for a domain socket transport too. Should have patches ready within the new few days.
02/02/2006 - I have a newer tree that's working for most ops. I'm beginning to check for regressions with xm-test. I'll post code soon.
01/22/2006 - Tiny bit more hacking. I'm exposing all of the functions in XendDomain, XendDomainInfo, XendNode, and XendDmesg which should be enough for xm to function. I'm currently use XendClient to provide a backwards compatible interface to xm.
01/20/2006 - I added a bundle containing a ~30 line XML-RPC server. It exports all of the functions from XendDomain and a bunch from XendDomainInfo. I think the appropriate way to approach this is to continue filling out the XML-RPC server, until XendClient.py can be changed to only use XML-RPC. Then we can check for regressions and check in leaving the HTTP server shut off. After we standardize the XML-RPC interface, we can then remove all of the HTTP infrastructure.
