Jump to: navigation, search

Difference between revisions of "XenAPI"

 
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
* '''Launchpad Entry''': [[NovaSpec]]:austin-xenapi
 
* '''Launchpad Entry''': [[NovaSpec]]:austin-xenapi
* '''Created''':
+
* '''Created''': 7 September 2010
* '''Contributors''':  
+
* '''Contributors''': Ewan Mellor
  
 
== Summary ==
 
== Summary ==
 +
 +
[[XenServer]]: Commercial, supported product from Citrix.
 +
 +
Xen Cloud Platform: Open-source equivalent of [[XenServer]] (and the development project for the toolstack).
 +
 +
XenAPI: The management API exposed by [[XenServer]] and Xen Cloud Platform.
 +
 +
This specification covers Nova support for [[XenServer]] and Xen Cloud Platform through XenAPI.  Note that this does not imply support for other Xen-based platforms such as those shipped with RHEL 5 or SUSE.
  
 
== Release Note ==
 
== Release Note ==
  
This section should include a paragraph describing the end-user impact of this change.  It is meant to be included in the release notes of the first release in which it is implemented.  (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
+
Nova may now use [[XenServer]] or Xen Cloud Platform as a virtualization platform.
 
 
It is mandatory.
 
  
 
== Rationale ==
 
== Rationale ==
Line 17: Line 23:
  
 
== Assumptions ==
 
== Assumptions ==
 +
 +
The [[OpenStack]] project will not ship the XenAPI.py module.  Users will need to get that from http://wiki.xensource.com/xenwiki/XCP_SDK or http://community.citrix.com/cdn/xs/sdks.
  
 
== Design ==
 
== Design ==
  
You can have subsections that better describe specific parts of the issue.
+
The pre-existing interface between Nova and the virtualization platform is through libvirt, with various calls to libvirt (and virsh) from Nova's compute and monitoring layers. There is also a libvirt simulation module, for unit testing without making calls to the a platform.
 
 
== Implementation ==
 
 
 
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
 
 
 
=== UI Changes ===
 
 
 
Should cover changes required to the UI, or specific UI that is required to implement this
 
 
 
=== Code Changes ===
 
 
 
Code changes should include an overview of what needs to change, and in some cases even the specific details.
 
 
 
=== Migration ===
 
 
 
Include:
 
* data migration, if any
 
* redirects from old URLs to new ones, if any
 
* how users will be pointed to the new way of doing things, if necessary.
 
 
 
== Test/Demo Plan ==
 
 
 
This need not be added or completed until the specification is nearing beta.
 
 
 
== Unresolved issues ==
 
 
 
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
 
 
 
== BoF agenda and discussion ==
 
  
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
+
In order to add XenAPI support, we propose a new layer (nova.virt) that abstracts over the calls to libvirt.  Through this abstract interface, the main body of Nova can make virtualization calls without reference to any particular platform.  This interface will then be implemented by modules for libvirt (nova.virt.libvirt_conn), XenAPI (nova.virt.xenapi), or a simulator(nova.virt.fake).
  
 
----
 
----
 
[[Category:Spec]]
 
[[Category:Spec]]

Revision as of 21:01, 7 September 2010

  • Launchpad Entry: NovaSpec:austin-xenapi
  • Created: 7 September 2010
  • Contributors: Ewan Mellor

Summary

XenServer: Commercial, supported product from Citrix.
Xen Cloud Platform: Open-source equivalent of XenServer (and the development project for the toolstack).
XenAPI: The management API exposed by XenServer and Xen Cloud Platform.

This specification covers Nova support for XenServer and Xen Cloud Platform through XenAPI. Note that this does not imply support for other Xen-based platforms such as those shipped with RHEL 5 or SUSE.

Release Note

Nova may now use XenServer or Xen Cloud Platform as a virtualization platform.

Rationale

User stories

Assumptions

The OpenStack project will not ship the XenAPI.py module. Users will need to get that from http://wiki.xensource.com/xenwiki/XCP_SDK or http://community.citrix.com/cdn/xs/sdks.

Design

The pre-existing interface between Nova and the virtualization platform is through libvirt, with various calls to libvirt (and virsh) from Nova's compute and monitoring layers. There is also a libvirt simulation module, for unit testing without making calls to the a platform.

In order to add XenAPI support, we propose a new layer (nova.virt) that abstracts over the calls to libvirt. Through this abstract interface, the main body of Nova can make virtualization calls without reference to any particular platform. This interface will then be implemented by modules for libvirt (nova.virt.libvirt_conn), XenAPI (nova.virt.xenapi), or a simulator(nova.virt.fake).