[openstack-dev] [charms] Juju Charms for OpenStack

James Page james.page at ubuntu.com
Thu May 19 10:37:54 UTC 2016


Hi All

tl;dr Juju is a great way of deploying OpenStack, and we'd like the
OpenStack Charms for Juju to become a official OpenStack Project

read on if you want the full details....

Juju [0] is a service modelling tool that's been around since about 2010;
developed primarily by Canonical, Juju takes a high level approach to
modelling services and the relations between them (think cinder,
neutron-api, nova-cloud-controller), with the details on exactly how each
of those services is installed, configured, scaled-up, scaled-down, HA'ed
etc.. implemented by a charm for each of the services that form part of a
model;  Juju uses underlying providers (responsible for managing compute,
storage and network resources) to translate the model onto actual machine
resources - in the context of OpenStack, the MAAS (metal-as-a-service [1])
provider is used to deploy an OpenStack model, using the OpenStack Charms,
to a combination of physical servers and LXD containers running on those
servers.

The OpenStack Charms have been around for about the same time as Juju; I
think the first release we supported was OpenStack Diablo, and we've
updated, redesigned and re-factored the charms to support every OpenStack
release on Ubuntu since then.

The OpenStack Charms are a core part of the Ubuntu OpenStack teams approach
to distributing OpenStack on Ubuntu (we use them for all of our deployment
and testing CI, as well as for deploying production OpenStack Clouds at
Canonical's customers). As a result when OpenStack releases we've always
had aligned support in Ubuntu and the OpenStack charms for the latest
release.

The OpenStack charms (26 of them including some things not specifically
OpenStack such as Ceph, Percona XtraDB Cluster and RabbitMQ) are written in
Python; the code base has evolved a-lot over the years (once upon a time
they where bash scripts), as has the approach to writing best practice
charms, and we expect new OpenStack charms to take a slightly different
approach to charm authoring which should make writing a new OpenStack charm
much more lightweight (see [3]).

We migrated development to OpenStack project infrastructure (from its
original home in Launchpad and Bazaar branches) around 4 months ago at the
request of the TC from our original request to be formally recognised as an
OpenStack project; we now have some history that's readily re-viewable so
I've restored our request to become a formal OpenStack project:

 https://review.openstack.org/224797

The community of developers around the charms is not as diverse as I would
like, but we've had a number of contributions from developers at SDN and
storage vendors (who are also maintaining charms for their own solutions)
as well as contribution from CloudBase for enabling support for Microsoft
Hyper-V in a Juju deployed OpenStack Cloud (Juju and MAAS can deploy
WIndows machines as well).

We have some outstanding work to consolidate developer and user
documentation around the OpenStack charms, which the team currently expect
to complete in the next few months.

Cheers

James

[0] https://jujucharms.com/
[1] https;//maas.ubuntu.com/
[2] https://jujucharms.com/openstack
[3]
https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160519/869601fd/attachment.html>


More information about the OpenStack-dev mailing list