Juju service provider for XCP
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
> I'm the project lead for XCP , 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  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!
>  http://xen.org/products/cloudxen.html
>  http://wiki.xen.org/xenwiki/XAPI_on_Ubuntu
>  https://launchpad.net/xcp
Twas nice to meet you at the charm school session at uds. A xcp provider would
The best starting point for implementing a new provider is the base class for
the existing providers @
for reference the dummy implementation used for most of the non provider
specific unit tests is @
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 .
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
The base provider class takes care of the details of formatting cloud-init for
- 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.
- 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.
Let us know if you have any more questions, the dev team also hangs out
regularly in #juju.
 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