From 8a7d43e5b6c5d5676555c199c3958a4cbfa2c5ad Mon Sep 17 00:00:00 2001
From: Andrea Frittoli <andrea.frittoli@hp.com>
Date: Fri, 28 Mar 2014 09:52:18 +0000
Subject: [PATCH] add bp:cross-domain-testing

A new set of tests to verify cross-domain scenarios with
keystone v3.

Change-Id: I87ac45f7cd09224518e29df8f5d2097746c69401
---
 specs/cross-domain-testing.rst | 100 +++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)
 create mode 100644 specs/cross-domain-testing.rst

diff --git a/specs/cross-domain-testing.rst b/specs/cross-domain-testing.rst
new file mode 100644
index 0000000..adbf855
--- /dev/null
+++ b/specs/cross-domain-testing.rst
@@ -0,0 +1,100 @@
+::
+
+This work is licensed under a Creative Commons Attribution 3.0 Unported License.
+http://creativecommons.org/licenses/by/3.0/legalcode
+
+..
+  This template should be in ReSTructured text. The filename in the git
+  repository should match the launchpad URL, for example a URL of
+  https://blueprints.launchpad.net/tempest/+spec/awesome-thing should be named
+  awesome-thing.rst .  Please do not delete any of the sections in this
+  template.  If you have nothing to say for a whole section, just write: None
+  For help with syntax, see http://sphinx-doc.org/rest.html
+  To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
+
+=====================
+ Cross Domain Testing
+=====================
+
+https://blueprints.launchpad.net/tempest/+spec/cross-domain-testing
+
+A new set of tests to verify cross-domain scenarios with keystone v3.
+
+Problem description
+===================
+
+Keystone V3 introduces the concept of domains.
+
+http://api.openstack.org/api-ref-identity.html#Domain_Calls
+
+With keystone V2, the both names and IDs of keystone entities were
+globablly unique. In keystone V3, IDs remain globally unique, but
+names are scoped to a specific domain.
+
+We need to verify that the scope of IDs and names is properly implemented
+in keystone.
+
+We need to verify that that the introduction of domains and modified
+scope of names does not cause issues with the services consuming keystone.
+
+A example scenario is verifying that there is no visibility of resources
+such as keypairs or servers across a pair of identical username, tenant_name
+defined in two different domains.
+
+Proposed change
+===============
+
+Add two groups of tests:
+- Keystone scenario tests, to verify the correct scope of ID and name for
+  users, groups, roles and projects, as well as cross domain user / project
+  association.
+- Scenario tests for each service, to verify the impact of multi-domain
+  scenarios on existing services.
+
+Example test:
+
+::
+  TestAccount1: Domain1, UserName1, ProjectName1
+  TestAccount2: Domain2, UserName1, ProjectName1
+
+  Create a resource A with TestAccount1
+  Create a resource B with TestAccount2
+
+  Client obtains token1 via keystone v3 API for TestAccount1.
+  Client requests list of a resources using token1, verify that only A
+  is returned.
+
+Tests using keystone v3 shall be executed only if api_v3 is True.
+
+Alternatives
+------------
+
+None
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  Andrea Frittoli <andrea.frittoli@hp.com>
+
+Milestones
+----------
+
+Target Milestone for completion:
+  Juno-1
+
+Work Items
+----------
+
+None
+
+Dependencies
+============
+
+Availability of keystone V3 to obtain tokens in scenario tests depends on
+the implementation of multi-keystone-api-version-tests bp:
+
+https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests