206e6a0e10
ref: https://storyboard.openstack.org/#!/story/135 Use Endpoint ID as a unique identifier for clouds in refstack test uploads. Change-Id: I363531ccfbffc5ba76a7d95de6648ff2dd75a95d
146 lines
3.9 KiB
ReStructuredText
146 lines
3.9 KiB
ReStructuredText
==========================================
|
|
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
|