Merge pull request #3 from gnuoy/feature/charm-specs
Add first wave and charm specs
This commit is contained in:
commit
88d817efaf
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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 I’d like to be run
|
||||
against the cloud. I want to ble to set up and manage on-schedule jobs for
|
||||
multiple machines. I’d like a single point of control over their schedule.
|
||||
|
||||
As a devops engineer I’d like to be able to specify workflows needed for
|
||||
deploying environments consisting of multiple VMs and applications.
|
||||
|
||||
As a business process enforcer I’d 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 I’d 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
|
|
@ -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
|
|
@ -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
|
Loading…
Reference in New Issue