Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Kb277


Emulab FAQ: Using the Testbed: Is there a Web Service interface for common emulab tasks?

Emulab FAQ: Using the Testbed: Is there a Web Service interface for common emulab tasks?

>>Do you guys have a web service interface to the common emulab tasks that I could invoke from my Windows machine here at the office?

Well, not in the Microsoft WSDL/SOAP/.Net sense, but there is a good XMLRPC API back-end.

There are command-line programs for much of it, accessible to you from Ops. (Yeah, I know, there's that ssh thing again...) But read on:

>>It would be helpful if I could automate things like swapping experiments, checking node availability etc. For example, I'd like to automate the common need to swap out an experiment after a successful image creation. Or swap in a pending experiment when I see enough nodes of certain kind available. Or swap experiments in an out in a series depending on how many nodes I need. Or automatically create an image and swap out if my stuff is idle, before the system kicks me out.

Notice that ops:/usr/testbed/bin has a bunch of symlinks to to provide a common back-end script for those command-line front-ends. For example, swapexp shows the options for swapping experiments in and out. swapexp --help (or any of the commands) shows the help for, with the whole list of subcommands.

>>Maybe you already have an API in place?

Absolutely. Behind those scripts is an XMLRPC interface to Boss, authenticated by SSH keys or SSL certificates.

XMLRPC is SOAP from before objects were added to it, roughly. XMLRPC is mature, and quite pleasant to work with. is an example of driving it in Python, but it's language-independent, for example see the XMLRPC.NET library.

So you can:

  • Script common stuff at the shell command-line level, via ssh from your box or via an ssh login from your box to Ops. This is dead easy, of course, and exactly what most people do for automation beyond just using our web interface.
  • Run at your end, or code derived from it, to interface via XMLRPC.
  • Build an WSDL/SOAP wrapper around the XMLRPC for a Web Services Interface.

This last one is one way to implement what you're asking for, but territory we haven't scouted at all. Can you make a strong case for it?