Add 'Dashboard Impact' to default spec

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

specs/mitaka/ceilometer-integration.rst

@@ -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
 ==============
 

specs/mitaka/couchdb-backup-restore.rst

@@ -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
 ==============
 

specs/mitaka/datastore-log-operations.rst

@@ -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
 ==============
 

specs/mitaka/datastore-manager-refactor.rst

@@ -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
 ==============
 

specs/mitaka/db2-backup-restore.rst

@@ -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
 ==============
 

specs/mitaka/move-to-oslo-db.rst

@@ -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
 ==============
 

specs/mitaka/pgsql-incremental-backup.rst

@@ -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
 ==============
 

specs/mitaka/pgsql-replication.rst

@@ -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
 ==============
 

specs/mitaka/postgres-configuration-groups.rst

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

specs/mitaka/pxc-grow-shrink-cluster.rst

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

specs/mitaka/remove-sql-schema-downgrades.rst

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

specs/mitaka/volume-type-on-create.rst

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

specs/template.rst

@@ -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.