diff --git a/specs/newton/approved/aodh.rst b/specs/newton/approved/aodh.rst index 5137e67..5da5ec3 100644 --- a/specs/newton/approved/aodh.rst +++ b/specs/newton/approved/aodh.rst @@ -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. diff --git a/specs/newton/approved/barbican.rst b/specs/newton/approved/barbican.rst index 1f9305c..3b9551b 100644 --- a/specs/newton/approved/barbican.rst +++ b/specs/newton/approved/barbican.rst @@ -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 "" 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 diff --git a/specs/newton/approved/ceph-broker.rst b/specs/newton/approved/ceph-broker.rst index 9ee13c1..3215c8d 100644 --- a/specs/newton/approved/ceph-broker.rst +++ b/specs/newton/approved/ceph-broker.rst @@ -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. diff --git a/specs/newton/approved/cephfs.rst b/specs/newton/approved/cephfs.rst index 4ce3c54..e03194a 100644 --- a/specs/newton/approved/cephfs.rst +++ b/specs/newton/approved/cephfs.rst @@ -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 diff --git a/specs/newton/approved/charm-layering.rst b/specs/newton/approved/charm-layering.rst index 3e55313..05bb2a2 100644 --- a/specs/newton/approved/charm-layering.rst +++ b/specs/newton/approved/charm-layering.rst @@ -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 ============ diff --git a/specs/newton/approved/designate.rst b/specs/newton/approved/designate.rst index e9c0fd7..40c4828 100644 --- a/specs/newton/approved/designate.rst +++ b/specs/newton/approved/designate.rst @@ -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 "" 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 diff --git a/specs/newton/approved/keystone-federation.rst b/specs/newton/approved/keystone-federation.rst index 7d5da50..5e8f865 100644 --- a/specs/newton/approved/keystone-federation.rst +++ b/specs/newton/approved/keystone-federation.rst @@ -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 "" 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 diff --git a/specs/newton/approved/mistral.rst b/specs/newton/approved/mistral.rst index 9362069..fa37435 100644 --- a/specs/newton/approved/mistral.rst +++ b/specs/newton/approved/mistral.rst @@ -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 "" 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 diff --git a/specs/newton/approved/murano.rst b/specs/newton/approved/murano.rst index faf7aa7..e65a900 100644 --- a/specs/newton/approved/murano.rst +++ b/specs/newton/approved/murano.rst @@ -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 "" 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 diff --git a/specs/newton/approved/trove.rst b/specs/newton/approved/trove.rst index e0237c6..e2b9c2d 100644 --- a/specs/newton/approved/trove.rst +++ b/specs/newton/approved/trove.rst @@ -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 "" 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 diff --git a/specs/template.rst b/specs/template.rst index c228313..32f35b6 100644 --- a/specs/template.rst +++ b/specs/template.rst @@ -1,6 +1,6 @@ .. Copyright <--UPDATE THESE - + This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode