Use keystone uuid with cloud id
ref: https://storyboard.openstack.org/#!/story/135 Use Endpoint ID as a unique identifier for clouds in refstack test uploads. Change-Id: I363531ccfbffc5ba76a7d95de6648ff2dd75a95d
This commit is contained in:
Rob Hirschfeld
parent
d2d47f80a4
commit
206e6a0e10
|
|
@ -0,0 +1,145 @@
|
|||
==========================================
|
||||
Test Submission API should use Target Identity Endpoint UUID
|
||||
==========================================
|
||||
|
||||
story: "Use keystone uuid with cloud id"
|
||||
ref: https://storyboard.openstack.org/#!/story/135
|
||||
|
||||
|
||||
In order to ensure that multiple test runs are attributed to the same cloud,
|
||||
test runner needs to use a consistent, discoverable and unique identifier
|
||||
for each cloud test. This allows multiple users to correlate results from
|
||||
the same cloud.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Refstack is designed to have minimal user security and configuration overhead;
|
||||
consequently, there are no mechanisms in the short term to ensure that a user's
|
||||
test results are authorized (see note). To create valid results, refstack needs a way to
|
||||
know when multiple runs are against the same targets so that comparisons are valid.
|
||||
|
||||
> Note: In the future, Refstack will include user authentication. At that point
|
||||
it will be possible to associate uploaded data to users and vendors in an
|
||||
authoritative way.
|
||||
|
||||
To solve this problem, refstack needs a unique handle for each cloud tested
|
||||
that is unique and also discoverable to the test runner.
|
||||
|
||||
Some requirements:
|
||||
|
||||
* No round trips to refstack before a test is submitted (do not pre-create cloud)
|
||||
* Minimal trust of users (do not require user credentials for uploads)
|
||||
* Users should not be expected to remember cloud IDs
|
||||
* Multiple users of same cloud should be tracked together
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
When test runner submits results, it should submit with the Identity Endpoint
|
||||
UUID (aka Keystone end point under serviceCatalog/service["identity"]/endpoint[?id]).
|
||||
|
||||
The refstack API should accept EITHER the user's created refstack cloud ID or the
|
||||
discovered Endpoint UUID. If the refstack cloud ID is passed and no cloud
|
||||
exists then refstack should create a new refstack cloud.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Refstack could use a different endpoint for the ID
|
||||
|
||||
Refstack could stop using its own cloud ID and only use endpoint IDs
|
||||
|
||||
Possible addition: we may want to also track the cloud endpoint URL. This
|
||||
could be a possible added field for the JSON upload. While this will
|
||||
help identify clouds, it could also reveal more information than the
|
||||
user wants disclosed. We should only implement this with user permission.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
We have to add the endpoint ID as a field into the Cloud model.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
The Test Upload API needs to be modified to accept either the Test ID or the
|
||||
endpoint UUID. If the endpoint UUID is not in the URL then it should be included
|
||||
in the JSON payload.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Improvement: this helps reduce the need of passing refstack authentication to ensure
|
||||
that cloud results are linked to individual clouds or users.
|
||||
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
Users will not have to pre-create clouds before using
|
||||
refstack.
|
||||
|
||||
Users will have to be able to assign clouds to endpoint UUIDs.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Should improve performance because round trips on result
|
||||
uploads are avoided.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Should simplify developer work.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
TBD
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* determine forumula for endpoint UUID (if any needed)
|
||||
* get and add cloud epid to results upload
|
||||
* add cloud epid to model
|
||||
* update api to response correctly for epid lookup
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
API v1 spec.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
We need to validate the endpoint IDs correctly resolve to clouds.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
We should explain how clouds are identified in the documentation so that
|
||||
users will understand the impact of re-installing and how to keep results
|
||||
together even if the cloud changes.
|
||||
|
||||
We will also have to explain how to associate results to a user managed
|
||||
cloud.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
https://storyboard.openstack.org/#!/story/135
|
||||
Loading…
Reference in New Issue