Merge pull request #3 from gnuoy/feature/charm-specs

Add first wave and charm specs
This commit is contained in:
James Page 2016-06-07 17:36:39 +01:00
commit 88d817efaf
7 changed files with 1027 additions and 0 deletions

View File

@ -0,0 +1,128 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
==================
Aodh Charm Support
==================
Aodh (alarms and notifications based on metrics) is maturing and fit into the
Canonical view of core infrastructure projects for OpenStack; Ubuntu main
inclusion, charming and full QA to allow Canonical customers to deploy and use.
Problem Description
===================
Aodh provides a method generating alarms and notifications based on metrics.
Proposed Change
===============
Aodh will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
The new Aodh charm should include, as a minimum, the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
Manually review metrics and trigger alarms
Implementation
==============
Assignee(s)
-----------
Primary assignee:
jamespage
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t aodh
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Aodh to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Aodh - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide Aodh charm
==================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Aodh.
- Add support for upgrading Aodh
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Aodh in a highly available configuration
- Add support for the Aodh to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Mojo specification deploying and testing Aodh
#############################################
- Write Mojo spec for deploying Mojo in an HA configuration and testing
automatic and manual creation of DNS records.
Repositories
------------
git@github.com:openstack-charmers/charm-aodh.git
Documentation
-------------
The Aodh charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
No additional security concerns.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
- Provide mongodb interface
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status

View File

@ -0,0 +1,149 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
===============================
Barbican Charm Support
===============================
OpenStack Key Manager (Barbican) is maturing and fits into the Canonical view
of core infrastructure projects for OpenStack; Ubuntu main inclusion, charming
and full QA to allow Canonical customers to deploy and use.
Problem Description
===================
OpenStack services and users often need a repository to store sensitive
information like passwords, cryptographic keys etc. The Barbican service
provides an interface on top of an HSM for doing that.
Proposed Change
===============
Barbican will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
One new charm - Barbican; Charm needs to take into account potential use of
backed hardware security modules (HSM) - this might be nicely done using the
cinder-backend approach as a subordinate charm to avoid polluting the main
charm with details of every HSM possible.
The new charm, as a minimum, should include the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
Secrets stored via other means outside of OpenStack.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
ajkavanagh
gnuoy
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t barbican
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Barbican to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Barbican - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide base and interface layers required for OpenStack charms
===============================================================
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
- Provide pgsql interface layer
- Provide keystone interface layer
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status
Provide Barbican charm
===============================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Barbican.
- Add support for upgrading Barbican
- Add config option and accompanying support to enable barbicans use of
configurable storage backends: ie. HSM (hardware security module)
NOTE: configuration without HSM is not secure and is for testing purposes
only.
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Barbican in a highly available configuration
- Add support for the Barbican to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Mojo specification deploying and testing Barbican
#################################################
- Write Mojo spec for deploying Mojo in an HA configuration and testing
storage and retrieval of secrets.
Repositories
------------
git@github.com:openstack-charmers/charm-barbican.git
Documentation
-------------
The Barbican charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
Given the purpose of Barbican is to store and manage secrets a review of the
charm by the security team may be appropriate.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
None

View File

@ -0,0 +1,151 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=======================
Designate Charm Support
=======================
OpenStack DNS (Designate) is maturing and fit into the Canonical view of core
infrastructure projects for OpenStack; Ubuntu main inclusion, charming and full
QA to allow Canonical customers to deploy and use.
Problem Description
===================
Designate (DNSaaS) provides a method for managing DNS records for addressing
OpenStack guests and floating IPs.
Proposed Change
===============
Designate will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
Two new charms - designate and designate-bind - designate provides the API/RPC
services, and bind provides a flexible scale out service for managing BIND DNS
servers; the interfaces between the two charms should be sufficiently flexible
to allow different DNS backends to be plugged in at a later date if require
(i.e. a PowerDNS charm instead of BIND).
The new Designate charm should include, as a minimum, the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
DNS records could be managed manually in an existing DNS server.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
gnuoy
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t designate
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Designate to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Designate - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide Designate charm
========================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Designate.
- Add support for upgrading Designate
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Designate in a highly available configuration
- Add support for the Designate to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Provide Designate Bind charm
========================
- Create bind charm designed to integrate with designate.
- Ensure charm meets basic non-functional requirements, such as HA and workload
status
Extend Designate charm
======================
- Add support for Designate integration with Neutron to extend the
automatically created record information.
Mojo specification deploying and testing Designate
##################################################
- Write Mojo spec for deploying Mojo in an HA configuration and testing
automatic and manual creation of DNS records.
Repositories
------------
git@github.com:openstack-charmers/charm-designate.git
Documentation
-------------
The Designate charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
No additional security concerns.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
- Provide pgsql interface layer
- Provide keystone interface layer
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status

View File

@ -0,0 +1,179 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
===========================
Keystone Federation Support
===========================
Keystone Federation is a maturing feature and charm support for it is a
frequently requested.
Problem Description
===================
Single identity across a cloud with multiple, geographically disparate regions
is complex for operators; Keystone federation provides the ability for multiple
clouds to federate identity trusty between regions, supporting single identity
either via keystone or via a 3rd party identity provider. The use of Keystone
Federation will help us build bigger, more manageable clouds across
geographies.
Proposed Change
===============
The design of this solution is predicated on the use of the Keystone federation
features introduced in OpenStack Kilo; these allow Keystone to delegate
authentication of users to a different identity provider (IDP) which might be
keystone, but could also be a solution implementing one of the methods used for
expressing assertions of identity (saml2 or OpenID).
If IDP is keystone, then this is the current straw man
design:
- A single global keystone is set-up as the IDP for the cloud; this service
provides authentication for users and the global service catalog for all
cloud regions.
- Region level keystone instances delegate authentication to the global
keystone, but also maintain a region level service catalog of endpoints
for local use
An end-user accesses the cloud via the entry point of the global keystone; at
this point the end-user will be redirected to the region level services based
on which region they which to manage resources within.
In terms of charm design, the existing registration approach for services in
keystone is still maintained, but each keystone deployment will also register
its service catalog entries into the global keystone catalog.
They keystone charm will need updating to enable a) operation under apache
(standalone to be removed in mitaka and b) enablement of required federation
components. There will also be impact onto the openstack-dashboard charm to
enable use of this feature.
There is also a wider charm impact in that we need to re-base onto the keystone
v3 api across the board to support this type of feature.
The packages to support identity federation will also need to be selected and
undergo MIR into Ubuntu main this cycle; various options exist:
- SAM: Keystone supports the following implementations:
Shibboleth - see Setup Shibboleth.
Mellon - see Setup Mellon.
- OpenID Connect: see Setup OpenID Connect.
The Keystone Federation feature should support:
- Federation between two keystone services in the same model
- Federation between two keystone services in different models
- Federation between keystone and an identity provider not managed by Juju
Alternatives
------------
Identities can be kept in sync between keystone instances using database
replication. The keystone charm also supports using LDAP as a backend, keystone
charms in different models could share the same LDAP backend if there service
users are stored locally.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
gnuoy
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t keystone_federation
Work Items
----------
Keystone Investigative Work
===========================
- Deploy multiple juju environments and define one IDP keystone and the rest as
SPs. Configuration will be manually applied to units
- Test OpenID integration with keystone. Configuration will be manually applied
to units
Keystone v3 endpoint enablement
===============================
- Define intercharm protocol for agreeing keystone api version
- Enable Keystone v3 in keystone charm
- Enable Keystone v3 in client charms
- Update Openstack charm testing configuration scripts to talk keystone v3
- Create Mojo spec for v3 deploy
Keystone to keystone Federation enablement
==========================================
- Switch keystone to use apache for all use cases on deployments >= Liberty
- Enable keystone to keystone SP/IDP relation using a config option in the
charm to define the IDP endpoint (in lieu of cross environment relations)
- Mojo spec to deploy two regions and test federated access
Keystone to OpenID 3rd party enablement
=======================================
- Backport libapache2-mod-auth-openidc to trusty cloud archive
- Expose OpenID configuration options to keystone charm, and update keystone
apache accordingly.
- Create bundle for deploying a single region using UbuntuONE for authentication.
- Mojo spec for multi-region UbuntuONE backed deployment
Keystone to SAML 3rd party enablement
=====================================
- Expose SAML configuration options to keystone charm, and update keystone apache
accordingly.
- Create bundle for deploying a single region using SAML for authentication.
- Mojo spec for multi-region SAML backed deployment
Repositories
------------
No new repositories
Documentation
-------------
The Keystone charm README will be updated with instructions for enabling
federatioon. A blog post is optional but would be a useful addition.
Security
--------
Security review may be required.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
None

View File

@ -0,0 +1,147 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Mistral Charm Support
=====================
To add a service to Openstack to set up and manage on-schedule jobs for
multiple machine.
Problem Description
===================
As a cloud administrator I have maintenance jobs that Id like to be run
against the cloud. I want to ble to set up and manage on-schedule jobs for
multiple machines. Id like a single point of control over their schedule.
As a devops engineer Id like to be able to specify workflows needed for
deploying environments consisting of multiple VMs and applications.
As a business process enforcer Id like to be able to make a request to run a
complex multi-step business process and have it be fault-tolerant so that if
the execution crashes at some point on one node then another active node of the
system can automatically take on and continue from the exact same point where
it stopped.
As a data analyst I need a tool for data crawling. Eg Id like to be able to
express as a graph the related tasks I need in order to prepare a financial
report.
Proposed Change
===============
Mistral will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
One new charm - Mistral with corresponding tests and QA CI/setup.
The new Mistral charm should include, as a minimum, the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
Jobs could scheduled manually via cron on each machine.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
unknown
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t mistral
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Mistral to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Mistral - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide Mistral charm
========================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Mistral.
- Add support for upgrading Mistral
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Mistral in a highly available configuration
- Add support for the Mistral to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Mojo specification deploying and testing Mistral
================================================
- Write Mojo spec for deploying Mojo in an HA configuration and testing
creation of jobs.
Repositories
------------
git@github.com:openstack-charmers/charm-mistral.git
Documentation
-------------
The Mistral charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
No additional security concerns.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
- Provide pgsql interface layer
- Provide keystone interface layer
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status

View File

@ -0,0 +1,140 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Murano Charm Support
=====================
To add a service to Openstack provide a catalogue of applications deployable
on Openstack.
Problem Description
===================
To provide UI and API which allows to compose and deploy composite
environments on the Application abstraction level and then manage their
lifecycle. The Service should be able to orchestrate complex circular dependent
cases in order to setup complete environments with many dependent applications
and services. However, the actual deployment itself will be done by the
existing software orchestration tools (such as Heat), while the Murano project
will become an integration point for various applications and services.
Proposed Change
===============
Murano will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
One new charm - Murano with corresponding tests and QA CI/setup.
The new Murano charm should include, as a minimum, the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
Jobs could scheduled manually via cron on each machine.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
unknown
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t murano
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Murano to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Murano - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide Murano charm
========================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Murano.
- Add support for upgrading Murano
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Murano in a highly available configuration
- Add support for the Murano to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Mojo specification deploying and testing Murano
================================================
- Write Mojo spec for deploying murano in an HA configuration and testing
creation of jobs.
Repositories
------------
git@github.com:openstack-charmers/charm-murano.git
Documentation
-------------
The Murano charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
No additional security concerns.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
- Provide pgsql interface layer
- Provide keystone interface layer
- Provide horizon interface layer
- Provide heat interface layer
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status

View File

@ -0,0 +1,133 @@
..
Copyright 2016, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Trove Charm Support
=====================
To add a service to Openstack to provide on-demand databases.
Problem Description
===================
As a cloud user I need be able to deploy a database that is scalable and
reliable quickly and easily without the burden of handling complex
administrative tasks.
Proposed Change
===============
Trove will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
One new charm - Trove with corresponding tests and QA CI/setup.
The new Trove charm should include, as a minimum, the following features:
- Deployable in a highly available configuration
- Allow clients and services to interact using SSL encryption
- Charm progress displayed via workload status
Alternatives
------------
Juju delpoy {mysql,percona-cluster,cassandra,etc}
Implementation
==============
Assignee(s)
-----------
Primary assignee:
unknown
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t trove
Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
- Package updates for Trove to strip all debconf/dbconfig related code from
the packaging.
- MIR review for Trove - Evaluate package and source according to
https://wiki.ubuntu.com/MainInclusionProcess, open corresponding bug, work
with Ubuntu MIR team and make any other necessary package changes to get
package into main.
Provide Trove charm
========================
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Trove.
- Add support for upgrading Trove
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Trove in a highly available configuration
- Add support for the Trove to display workload status
- Add support SSL endpoints
- Charm should have unit and functional tests.
Mojo specification deploying and testing Trove
================================================
- Write Mojo spec for deploying Trove in an HA configuration and testing
creation of databases.
Repositories
------------
git@github.com:openstack-charmers/charm-trove.git
Documentation
-------------
The Trove charm should contain a README with instructions on deploying the
charm. A blog post is optional but would be a useful addition.
Security
--------
No additional security concerns.
Testing
-------
Code changes will be covered by unit tests; functional testing will be done
using a combination of Amulet, Bundle tester and Mojo specification.
Dependencies
============
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
- Provide pgsql interface layer
- Provide keystone interface layer
- Provide hacluster interface layer
- Provide nrpe-external-master interface layer
- Provide OpenStack base layer with all common hook code that is not already
covered by an interface layer.
- Provide OpenStack base layer with support for HA deployments
- Provide OpenStack base layer with support for SSL communication
- Provide OpenStack base layer with support for workload status