<div dir="ltr">Hi All<div><br></div><div>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</div><div><br></div><div>read on if you want the full details....</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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]).</div><div><br></div><div>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:</div><div><br></div><div> <a href="https://review.openstack.org/224797">https://review.openstack.org/224797</a></div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div><br></div><div>James</div><div><br></div><div>[0] <a href="https://jujucharms.com/">https://jujucharms.com/</a></div><div>[1] https;//<a href="http://maas.ubuntu.com/">maas.ubuntu.com/</a></div><div>[2] <a href="https://jujucharms.com/openstack">https://jujucharms.com/openstack</a></div><div>[3] <a href="https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md">https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md</a></div><div><br></div></div>