openstack/trove-specs
Code Issues Proposed changes

Add 'Dashboard Impact' to default spec

Browse Source 
Added a new Dashboard Impact section to the Trove spec default
document to track the UX changes for new features.

Updated existing specs to have the section (so they pass py27).

Change-Id: I8981aa8c577b46fea894dd531a98d283880ea9fc
This commit is contained in:
Peter Stachowski 2016-01-06 18:51:59 +00:00
parent c590a574fc
commit f200cf24df
13 changed files with 99 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
specs/mitaka/ceilometer-integration.rst
View File

@ -373,6 +373,12 @@ the direction of allowing the guest to operate in an isolated
environment.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

7
specs/mitaka/couchdb-backup-restore.rst
View File

@ -140,6 +140,13 @@ When replication is enabled for a database from a source to target system, it
uses the document revision numbers to track differences and detect conflicts
and resolve it.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/datastore-log-operations.rst
View File

@ -786,6 +786,12 @@ Trove user. This could be enhanced (in the future) to have the admin user
provide a tenant that could be used to host the log containers.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/datastore-manager-refactor.rst
View File

@ -479,6 +479,12 @@ useful, it could be added in addition to the proposed method as a means of
notification only.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/db2-backup-restore.rst
View File

@ -176,6 +176,12 @@ Trove. Once users can configure other logging options like archive logging,
online backup can be implemented.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

7
specs/mitaka/move-to-oslo-db.rst
View File

@ -84,6 +84,13 @@ Alternatives
Determine the root cause of the database connection mismanagement [3]_.
Previous efforts were unsuccessful.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/pgsql-incremental-backup.rst
View File

@ -235,6 +235,12 @@ something potentially unexpected and not consistent with the approach to
incremental backups on other datastores.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

7
specs/mitaka/pgsql-replication.rst
View File

@ -238,6 +238,13 @@ Slony provides master-slave replication using table-level triggers. It has
greater overhead on the master database than standard streaming replication,
but has the benefit of table-level granularity.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

7
specs/mitaka/postgres-configuration-groups.rst
View File

@ -121,6 +121,13 @@ Alternatives
None
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

7
specs/mitaka/pxc-grow-shrink-cluster.rst
View File

@ -198,6 +198,13 @@ Alternatives
Not to support grow and shrink of a pxc cluster.
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/remove-sql-schema-downgrades.rst
View File

@ -100,6 +100,12 @@ Alternatives
None
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

6
specs/mitaka/volume-type-on-create.rst
View File

@ -140,6 +140,12 @@ Alternatives
None
Dashboard Impact (UX)
=====================
TBD (section added after approval)
Implementation
==============

22
specs/template.rst
View File

@ -135,6 +135,25 @@ This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Dashboard Impact (UX)
=====================
This section should detail how the dashboard (Horizon) should display the new
changes, if relevant. For example, if adding cluster support for Redis, this
section could say::
Enabling Redis clustering will simply reuse the existing Launch Cluster
dialog. The Redis datastore will be in the datastore pulldown. When the
user selects Redis the Launch Cluster dialog fields will dynamically
change to display the default Launch Cluster fields.
There will be a new detail overview panel with Redis cluster specific
information.
There are no additional actions to be added at this point for the Redis
cluster.
Implementation
==============
@ -150,6 +169,9 @@ primary author and contact.
Primary assignee:
<launchpad-id or None>
Dashboard assignee:
<launchpad-id or None>
Can list additional ids if they intend on doing substantial implementation work
on this spec.