Open Stack

+1 from me (as an OpenStack contributor, and one of those 'developers at
SDN and storage vendors' :-) ).

  Neil


On Thu, May 19, 2016 at 11:38 AM James Page <james.page at ubuntu.com> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160519/efae826a/attachment.html>