Juju service provider for XCP

Kapil Thangavelu kapil.thangavelu at canonical.com
Mon Nov 7 15:12:36 UTC 2011


Excerpts from Mike McClurg's message of Fri Nov 04 14:48:11 -0400 2011:
> Hi all,
> 
> I'm interested in creating a new service provider for Juju, and I was
> hoping someone could give me some pointers. First, a little background
> info:
> 
> I'm the project lead for XCP [1], which is an open source
> virtulization platform based on the Xen hypervisor. XCP is the open
> source version of Citrix's XenServer platform. We're currently working
> on project [2][3] to port the XCP from CentOS to Ubuntu Server. This
> will basically let you do 'apt-get install xcp', and have a system
> that is functionally equivalent to a Citrix XenServer.
> 
> In the process of porting our software to Ubuntu, we've discovered
> Juju. We on the XCP team think it would be really great to provide a
> Juju service provider for XCP and XenServer. For comparison purposes,
> this kind of service provider would be similar to the OpenStack
> service provider, except that an OpenStack installation could
> potentially provide a few orders of magnitude more infrastructure than
> a pool of XCP hosts would.
> 
> So, what does it take to create a new service provider for Juju? Is an
> XCP/XenServer service provider something that the Juju community is
> interested in? Thanks for the help!
> 
> Mike
> 
> [1] http://xen.org/products/cloudxen.html
> [2] http://wiki.xen.org/xenwiki/XAPI_on_Ubuntu
> [3] https://launchpad.net/xcp
> 

Hi Mike,

Twas nice to meet you at the charm school session at uds. A xcp provider would 
be great.

The best starting point for implementing a new provider is the base class for 
the existing providers @
http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/common/base.py

for reference the dummy implementation used for most of the non provider 
specific unit tests is @
http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/dummy.py


A full provider implementation has a few responsibilities

 - machine management (launch/destroy/list)

Basic ability to start, stop and list the started virtual machines. Its expected 
that the provider has an existing library of machine images that can be utilized 
for this purpose. At the moment the only requirement by juju on image or physical 
machine selection is the ability to map a release name to such an image [1].

A provider is expected to return a provider specific machine class 
with some common attributes (ip address, provider specific id, state of 
machine). Juju keep its own mapping of a machine id to an internal provider id.

 - cloud-init seeding on started machines.

Juju uses cloud-init as its entry point into a machine. The cloud-init data file 
can be placed on disk to seed it, there's some more docs/example on how this 
works here.

http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/seed/

The base provider class takes care of the details of formatting cloud-init for 
the provider.

 - file storage

A blob storage with R/W access from the juju client and the provider agent, and 
accessible to all launched machines in a read only fashion. Its used to store 
the location of zookeeper for the client, and for deployed charms for the units.

We currently have a few different implementations of provider storage, s3 for 
aws, webdav for orchestra, and a file directory (client rw) + webserver (unit r) 
for the lxc local provider.

The directory implementation used for tests is here.
http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/common/files.py

 - exposed port management (open-port, close-port, get-opened-ports)

Juju relies on the provider to firewall the environment, and explicitly upon a 
`juju expose <service-name>` has the provider expose the requested ports to 
public acces. atm this is only implemented for the EC2/openstack provider.

 - exposing provider specific config

can be done in the environments.yaml, their validated against a schema defined
in this module.

http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/environment/config.py

Let us know if you have any more questions, the dev team also hangs out 
regularly in #juju.

cheers,

Kapil

[1] There's been some ongoing discussion on placement/resource constraints when 
deploying services or adding units, which will extend the provider requirements
in this regard. There will be a specification and discussion of that capability 
on list prior to implementation.



More information about the Juju mailing list