Tidy formatting and get tests passing again
This commit is contained in:
parent
3121e5fb50
commit
26c2c043d8
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 else’s 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 else’s
|
||||
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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
============
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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 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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue