openinfra/refstack
Code Issues Proposed changes
e6fd078a8b
refstack/specs/mitaka/implemented/use-url-as-cpid.rst
Luz Cazares eebbd714f1 Fix specs format to improve rendered documentation 
Several existing Refstack specs doesn't have the spec
name header resulting in a bad documentation formatting.
Added or fixed spec name headers under existing spec
folder so that documentation is rendered and displayed
correctly.

Change-Id: I20d0c140ddc132fad90e2b7152c71599a22a1dd8
2016-08-10 22:35:00 +00:00

3.4 KiB
Executable File
Raw Blame History

Use Cloud URL as the Cloud Provider ID (CPID)

Launchpad blueprint:

This spec proposes RefStack to add a method to use the cloud access URL as the base to generate the CPID.

Problem description

As defined in the "Test Submission API should use Target Identity Endpoint UUID" specification (refstack-org-api-cloud-uuid.rst). Currently, RefStack uses the cloud's Identity (Keystone) UUID as the CPID.

For Keystone V2 API, this ID can be the ID of any one of the three access endpoints, namely admin, public or private endpoints. However, for Keystone V3 API, this ID is the ID of the Keystone service. Furthermore, when testing a distro product, the Identity ID will be different every time a cloud is stood up, regardless that whether this cloud is built by the same person, with exactly the same OpenStack code and configuration. In such circumstances, multiple CPIDs could represent a single cloud.

We have also encountered some cases that the cloud's Keystone does not even returns the identity service ID in the tokens it returns. In addition, there is recent request for RefStack to support uploading test results that were not collected using refstack-client. These type of data in subunit format won't have CPID created at testing time. RefStack should provide a method to generate CPID without the need of re-connecting to the cloud again.

Proposed change

In addition to the current practice of using the different types of Identity ID for CPID, RefStack should add additional support to generate the CPID based on the cloud URL. This will also be used as the failover method for CPID.

Alternatives

For consistency, RefStack should consider to only use the cloud access URL to generate the UUID for CPID. In consequence, RefStack no longer has to keep track and adjust to changes in Keystone client and API for retrieving the the CPID.

Open to other suggestions.

Data model impact

None.

There is no data modal change needed.

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

With this failover addition, refstack-client should never again fail due to CPID retrieval error. This also allows RefStack to provide users with an option to upload data in subunit format.

Performance Impact

None

Other deployer impact

There is possibility of CPIDs being the same for two different clouds. This can happen primarily in the private address space, where people may have use the same IP address such as 192.168.. (or whatever commonly used default addresses) for keystone address. Since this likely won't be the case with actual production clouds and it is a last resort, we are okay with this possibility.

Furthermore, RefStack is no longer completely dependent on whether or not the cloud's Keystone even returns the Identity service ID in the tokens it returns.

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

TBD

Other contributors:

TBD

Work Items

  • Develop code to generate CPID based on access URL

Dependencies

None

Testing

None

Documentation Impact

None

References

None