[workspace-dev] Plugin development/Integration with OpenNebula

[William Voorsluys]

Hello,

I would like to present the most current issues about our VWS/ONE integration.

In this integration, we are considering handling an ONE-managed
cluster as a new back-end implementation for VWS.

We were initially considering handling a cluster as a black box, i.e.
something like considering it as just another host in a pool of
resources available to VWS, with N CPUs and an amount of memory equal
to the sum of all cluster nodes' memories (say 20GB). In fact, this is
how the current integration between VWS and ONE works; a new
implementation of the workspace-control scripts has been created for
this purpose. However, this approach allows VWS to send requests that
ONE is unable to schedule, for example a request for a VM with 4GB of
memory, while each cluster node has 2GB.

So, our approach will still be trying to hide as many as ONE details
as possible, but some internal information about a ONE cluster will
still be required. In this sense what we need to do is pretty much
adding a new back-end implementation for a new hypervisor and some
changes in the Slot Manager.

More specifically, we're considering the following code changes:

       1. Extending WorkspaceRequest to create various ONE VM specific
tasks, such as start, suspend, resume, etc. For some tasks, it will be
possible to reuse some of the classes that extend XenTask such as
Propagate. The new tasks will call ONE's XML-RPC API.

   2. Changing RequestFactory to add the new backend implementation
and its tasks.

   3. Extending DefaultSlotManagement and adapt it to ONE needs. For
instance, the new slot manager will get information about ONE's hosts
via its XML-RPC API. The manager needs to know how many hosts are
available in a certain cluster as well as their capacities in terms of
memory and number of CPUs.
Adding advance reservations support would also require changes in the
Slot Manager, as already pointed out on comments from the
SlotManagement interface. However, this seems to require non trivial
work, such as changes in several classes (SlotManagement derived
classes, NodeRequest, etc). Anyway, I was not planning to support AR
right now.

   4. Handling the XML schema additions previously discussed in this
thread would not be complicated, but a matter of adding support for
new information into VirtualMachineDeployment and DataUtil.

   5. Regarding the Scheduler, I first thought it would be
significantly changed, but I now realize we can rely on the current
scheduler implementation, since most of the work is in fact done by
the Slot Manager.

Still regarding a new back-end implementation, I noticed that the
Workspace Service currently supports one implementation to be used at
a time, i.e. hosts running different hypervisors cannot coexist on
resource pools. I'd like to ask if this is really how it is meant to
be, or we should use multiple service instances to handle distinct
pools, or am I missing something regarding this matter?

We would appreciate any comments about the approach we just proposed.
Also, we would like to get an idea about how these additions would fit
in a potential new VWS internal architecture. I mean, is there
something we should consider right now so that this integration would
survive any major redesign of VWS?

Cheers,

William.