Tidy formatting and get tests passing again

This commit is contained in:
James Page 2016-06-08 15:15:16 +01:00
parent 3121e5fb50
commit 26c2c043d8
11 changed files with 250 additions and 193 deletions

View File

@ -1,6 +1,6 @@
..
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
@ -69,7 +69,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Aodh to strip all debconf/dbconfig related code from
the packaging.
@ -79,7 +79,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide Aodh charm
==================
++++++++++++++++++
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Aodh.
@ -92,7 +92,7 @@ Provide Aodh charm
- 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.

View File

@ -1,6 +1,6 @@
..
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
@ -12,13 +12,12 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
===============================
Barbican Charm Support
===============================
==============
Barbican Charm
==============
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.
Provide a charm for deploying Barbican with support for associated
HSM modules/devices.
Problem Description
===================
@ -30,7 +29,7 @@ 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
Barbican will need to undergo MIR review for main inclusion; this process
should include stripping of all debconf/dbconfig related code from the
packaging.
@ -63,7 +62,7 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "barbican" for all patches related to this spec.
.. code-block:: bash
@ -73,7 +72,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Barbican to strip all debconf/dbconfig related code from
the packaging.
@ -83,7 +82,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide base and interface layers required for OpenStack charms
===============================================================
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Provide rabbitmq interface layer
- Provide mysql-shared interface layer
@ -98,7 +97,7 @@ Provide base and interface layers required for OpenStack charms
- 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.
@ -106,7 +105,7 @@ Provide Barbican charm
- 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.
only.
- Add config option and accompanying support for upgrades via
action-managed-upgrade.
- Add support for deploying Barbican in a highly available configuration
@ -115,7 +114,7 @@ Provide Barbican charm
- 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.
@ -123,12 +122,16 @@ Mojo specification deploying and testing Barbican
Repositories
------------
git@github.com:openstack-charmers/charm-barbican.git
A new git repository will be required for the Barbican charm:
.. code-block:: bash
git://git.openstack.org/openstack/charm-barbican
Documentation
-------------
The Barbican charm should contain a README with instructions on deploying the
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

View File

@ -22,24 +22,24 @@ Problem Description
===================
Some customers have asked how to connect a Juju deployed Ceph to an existing
OpenStack cluster that was deployed with home grown or someone elses tooling.
This causes a problem in that it is not possible to relate Ceph to the
OpenStack cluster.
OpenStack cluster that was deployed with home grown or someone elses
tooling. This causes a problem in that it is not possible to relate Ceph
to the OpenStack cluster.
Proposed Change
===============
A new charm will be created that acts a a broker between an existing Ceph deployment,
and a Juju deployed OpenStack Cloud; The charm will provide the same relations as
the existing ceph-mon charm.
A new charm will be created that acts a a broker between an existing Ceph
deployment, and a Juju deployed OpenStack Cloud; The charm will provide the
same relations as the existing ceph-mon charm.
Alternatives
------------
The alternative is manually connecting the Ceph and OpenStack together. This is
fine for some customers but not acceptable for bootstack. This kind of manual
configuration isn't particularly manageable.
The alternative is manually connecting the Ceph and OpenStack together.
This is fine for some customers but not acceptable for bootstack. This kind
of manual configuration isn't particularly manageable.
Implementation
==============
@ -61,7 +61,7 @@ Work Items
* Decide on which relations the OpenStack charm requires
* Expose all relations needed by way of config.yaml options.
* For every relation that OpenStack expects just return the config.yaml
values.
values.
Repositories
------------
@ -85,7 +85,7 @@ Testing
* Deploy OpenStack using juju.
* Deploy Ceph using juju.
* Deploy the Ceph-broker to a lxd container or a vm after filling out the
config.yaml
config.yaml
* Relate Ceph-broker to OpenStack and verify that OpenStack can talk to Ceph
* Mojo bundle tests will be used to show this works functionally.

View File

@ -16,27 +16,30 @@
CephFS
===============================
CephFS has recently gone GA and we can now move forward with offering
this to people as a charm. Up until this point it was considered too
experimental to store production data on.
CephFS has recently gone GA and we can now move forward with offering
this to people as a charm. Up until this point it was considered too
experimental to store production data on.
Problem Description
===================
A new CephFS charm will be created. This charm will leverage the Ceph base layer.
A new CephFS charm will be created. This charm will leverage the Ceph
base layer.
Proposed Change
===============
A new CephFS charm will be created. This charm will leverage the Ceph base layer.
The effort required should be small once the Ceph base layer is ready to go.
A new CephFS charm will be created. This charm will leverage the Ceph
base layer. The effort required should be small once the Ceph base
layer is ready to go.
Alternatives
------------
GlusterFS is an alternative to CephFS and will probably fit many users needs.
However there are users who don't want to deploy additional hardware to create
another cluster so this can be convenient in those cases.
GlusterFS is an alternative to CephFS and will probably fit many users
needs. However there are users who don't want to deploy additional
hardware to create another cluster so this can be convenient in those
cases.
Implementation
==============
@ -51,24 +54,37 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "cephfs" for all patches related to this spec.
.. code-block:: bash
git-review -t cephfs
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
1. Create the ceph-fs charm utilizing the base Ceph layer
- Expose interesting config items such as: mds cache size, mds bal mode
- Create actions to allow blacklisting of misbehaving clients, breaking of locks,
creating new filesystems, add_data_pool, remove_data_pool, set quotas, etc.
2. Create an interface to allow other charms to mount the filesytem.
ceph-fs charm
+++++++++++++
- Create the ceph-fs charm utilizing the base Ceph layer
- Expose interesting config items such as: mds cache size, mds bal mode
- Create actions to allow blacklisting of misbehaving clients, breaking
of locks, creating new filesystems, add_data_pool, remove_data_pool,
set quotas, etc.
cephfs-interface
++++++++++++++++
- Create an interface to allow other charms to mount the filesytem.
Repositories
------------
1. github.com/openstack/charm-ceph-fs
A new git repository will be required to host the ceph-fs charm:
.. code-block:: bash
git://git.openstack.org/openstack/charm-ceph-fs
Documentation
-------------
@ -85,7 +101,8 @@ Testing
-------
A mojo spec will be developed to exercise this charm along with amulet tests
if needed.
if needed:
* Deploy ceph-mon
* Deploy ceph-osd
* Deploy cephfs

View File

@ -12,32 +12,28 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
===============================
====================
Ceph Charms Layering
===============================
====================
The Ceph charms need to shed technical debt to allow faster iteration.
Problem Description
===================
There is lots of duplicate code in the ceph, ceph-mon, ceph-osd and ceph-radosgw
charms. The aim is to eliminate most of that using the new Juju layers approach.
There is lots of duplicate code in the ceph, ceph-mon, ceph-osd and
ceph-radosgw charms. The aim is to eliminate most of that using the
new Juju layers approach.
Proposed Change
===============
The new layering/reactive way of charming offers the Ceph charms significant
benefits. Between ceph-mon, ceph-osd, ceph and ceph-radosgw we have a lot of
duplicate code. Some of this code has been pulled out and put into the charmhelpers
library but that can't be done for everything. The juju layering approach to charms
will allow the rest of the shared code to be consolidated down into a base layer.
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
duplicate code. Some of this code has been pulled out and put into the
charmhelpers library but that can't be done for everything. The juju layering
approach to charms will allow the rest of the shared code to be consolidated
down into a base layer.
Alternatives
------------
@ -57,62 +53,80 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "layering" for all patches related to this spec.
.. code-block:: bash
git-review -t layering
Work Items
----------
1. Create a ceph base layer. These is the biggest piece of the project. All
duplicate code that is shared between ceph ceph-mon and ceph-osd will be consolidated
down into this base layer.
- Copy over unit tests
2. Create a ceph-mon layer that utilizes the ceph base layer. Once the base layer
ceph base layer
+++++++++++++++
These is the biggest piece of the project. All duplicate code that is
shared between ceph ceph-mon and ceph-osd will be consolidated down
into this base layer.
ceph-mon layer
++++++++++++++
Create a ceph-mon layer that utilizes the ceph base layer. Once the base layer
is settled the next step will be to build the ceph-mon charm on top of the base
layer.
- Copy over unit tests
3. Create a ceph-osd layer that utilizes the ceph base layer
- Copy over unit tests
4. Recreate the ceph charm by combining the ceph-osd + ceph-mon layers. With layering
the ceph charm essentially becomes just a combination of the other layers. We get this
almost for free and it should be easy to maintain all 3 charms going forward.
- Copy over unit tests
ceph-osd layer
++++++++++++++
Create a ceph-osd layer that utilizes the ceph base layer.
layer ceph charm
++++++++++++++++
Recreate the ceph charm by combining the ceph-osd + ceph-mon layers. With
layering the ceph charm essentially becomes just a combination of the other
layers. We get this almost for free and it should be easy to maintain all
3 charms going forward.
Repositories
------------
Will any new git repositories need to be created? Yes there will initially be
new repos created however these will migrate to the OpenStack repo.
1. https://github.com/ChrisMacNaughton/juju-interface-ceph-client
2. https://github.com/ChrisMacNaughton/juju-interface-ceph
3. https://github.com/ChrisMacNaughton/juju-interface-ceph-radosgw
4. https://github.com/ChrisMacNaughton/juju-interface-ceph-osd
5. https://github.com/ChrisMacNaughton/juju-layer-ceph-mon
6. https://github.com/ChrisMacNaughton/juju-layer-ceph-osd
The following repositories will need to be migrated to the /openstack
namespace with appropriate unit testing and CI:
1. https://github.com/ChrisMacNaughton/charm-interface-ceph-client
2. https://github.com/ChrisMacNaughton/charm-interface-ceph
3. https://github.com/ChrisMacNaughton/charm-interface-ceph-radosgw
4. https://github.com/ChrisMacNaughton/charm-interface-ceph-osd
5. https://github.com/ChrisMacNaughton/charm-layer-ceph-mon
6. https://github.com/ChrisMacNaughton/charm-layer-ceph-osd
Documentation
-------------
There shouldn't be any documentation changes needed for this. The aim to have
identical functionality to what was there before.
There shouldn't be any documentation changes needed for this. The aim to
have identical functionality to what was there before.
This will impact developer workflow because at some point we're going to have to
stop all posts to all the repos and cut over to this new version of the charm.
The repositories are also going to change. The goal is to publish them layered
version of the charm rather than the compiled bits. The test automation will
then compile the layered charm and use that for testing instead of just
cloning the repo like it does today.
This will impact developer workflow because at some point we're going to
have to stop all posts to all the repos and cut over to this new version
of the charm. The repositories are also going to change. The goal is to
publish them layered version of the charm rather than the compiled bits.
The test automation will then compile the layered charm and use that for
testing instead of just cloning the repo like it does today.
Security
--------
No additional security concerns.
Testing
-------
Because this is such a radical change from what we had
before the only way to accurately test it is to show identical functionality
to what we had before. A mojo spec will be used to demonstrate this.
Because this is such a radical change from what we had before the only
way to accurately test it is to show identical functionality to what we
had before. A mojo spec will be used to demonstrate this.
Dependencies
============

View File

@ -1,6 +1,6 @@
..
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
@ -12,18 +12,16 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=======================
Designate Charm Support
=======================
===============
Designate Charm
===============
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.
Charm OpenStack DNS (Designate).
Problem Description
===================
Designate (DNSaaS) provides a method for managing DNS records for addressing
Designate (DNSaaS) provides a method for managing DNS records for addressing
OpenStack guests and floating IPs.
Proposed Change
@ -62,7 +60,7 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "designate" for all patches related to this spec.
.. code-block:: bash
@ -72,7 +70,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Designate to strip all debconf/dbconfig related code from
the packaging.
@ -82,7 +80,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide Designate charm
========================
+++++++++++++++++++++++
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Designate.
@ -95,20 +93,20 @@ Provide Designate charm
- 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.
@ -116,12 +114,18 @@ Mojo specification deploying and testing Designate
Repositories
------------
git@github.com:openstack-charmers/charm-designate.git
New git repositories will be required for the Designate and
Designate Bind charms:
.. code-block:: bash
git://git.openstack.org/openstack/charm-designate
git://git.openstack.org/openstack/charm-designate-bind
Documentation
-------------
The Designate charm should contain a README with instructions on deploying the
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

View File

@ -1,6 +1,6 @@
..
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
@ -16,77 +16,78 @@
Keystone Federation Support
===========================
Keystone Federation is a maturing feature and charm support for it is a
Keystone Federation is a maturing feature and charm support for it is
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.
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).
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.
- 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.
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.
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.
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:
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
- 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.
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
==============
@ -100,7 +101,8 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "keystone-federation" for all patches related to this
spec:
.. code-block:: bash
@ -110,25 +112,26 @@ 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
- 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
- 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
@ -136,18 +139,20 @@ Keystone to keystone Federation enablement
- 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.
- 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.
+++++++++++++++++++++++++++++++++++++
- 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

View File

@ -1,6 +1,6 @@
..
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
@ -12,9 +12,9 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Mistral Charm Support
=====================
=============
Mistral Charm
=============
To add a service to Openstack to set up and manage on-schedule jobs for
multiple machine.
@ -24,16 +24,16 @@ 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.
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.
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.
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
@ -71,7 +71,7 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "mistral" for all patches related to this spec.
.. code-block:: bash
@ -81,7 +81,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Mistral to strip all debconf/dbconfig related code from
the packaging.
@ -91,7 +91,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide Mistral charm
========================
+++++++++++++++++++++
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Mistral.
@ -104,7 +104,7 @@ Provide Mistral charm
- 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.
@ -112,12 +112,16 @@ Mojo specification deploying and testing Mistral
Repositories
------------
git@github.com:openstack-charmers/charm-mistral.git
A new git repository will be required for the Mistral charm:
.. code-block:: bash
git://git.openstack.org/openstack/charm-mistral
Documentation
-------------
The Mistral charm should contain a README with instructions on deploying the
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

View File

@ -1,6 +1,6 @@
..
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
@ -12,9 +12,9 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Murano Charm Support
=====================
============
Murano Charm
============
To add a service to Openstack provide a catalogue of applications deployable
on Openstack.
@ -62,7 +62,7 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "murano" for all patches related to this spec.
.. code-block:: bash
@ -72,7 +72,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Murano to strip all debconf/dbconfig related code from
the packaging.
@ -82,7 +82,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide Murano charm
========================
++++++++++++++++++++
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Murano.
@ -95,7 +95,7 @@ Provide Murano charm
- 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.
@ -103,12 +103,16 @@ Mojo specification deploying and testing Murano
Repositories
------------
git@github.com:openstack-charmers/charm-murano.git
A new git repository will be required for the Murano charm:
.. code-block:: bash
git://git.openstack.org/openstack/charm-murano
Documentation
-------------
The Murano charm should contain a README with instructions on deploying the
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

View File

@ -1,6 +1,6 @@
..
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
@ -12,18 +12,18 @@
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
=====================
Trove Charm Support
=====================
===========
Trove Charm
===========
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
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.
administrative tasks.
Proposed Change
===============
@ -43,7 +43,9 @@ The new Trove charm should include, as a minimum, the following features:
Alternatives
------------
Juju delpoy {mysql,percona-cluster,cassandra,etc}
.. code-block:: bash
juju deploy {mysql,percona-cluster,cassandra,etc}
Implementation
==============
@ -57,7 +59,7 @@ Primary assignee:
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
Use Gerrit topic "trove" for all patches related to this spec.
.. code-block:: bash
@ -67,7 +69,7 @@ Work Items
----------
Provide fully supported packages for Ubuntu
===========================================
+++++++++++++++++++++++++++++++++++++++++++
- Package updates for Trove to strip all debconf/dbconfig related code from
the packaging.
@ -77,7 +79,7 @@ Provide fully supported packages for Ubuntu
package into main.
Provide Trove charm
========================
+++++++++++++++++++
- Create skeleton charm layer based on OpenStack base layer and available
interface layers to deploy Trove.
@ -90,7 +92,7 @@ Provide Trove charm
- 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.
@ -98,12 +100,16 @@ Mojo specification deploying and testing Trove
Repositories
------------
git@github.com:openstack-charmers/charm-trove.git
A new git repository will be required for the Trove charm:
.. code-block:: bash
git://git.openstack.org/openstack/charm-trove
Documentation
-------------
The Trove charm should contain a README with instructions on deploying the
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

View File

@ -1,6 +1,6 @@
..
Copyright <YEARS> <HOLDER> <--UPDATE THESE
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode