Add multiple OpenStack cloud support
Story: #2002126 Task: #22578 Change-Id: I3dbbf558290e144f649a740507747ac31dfc8b8c
This commit is contained in:
ricolin
parent
d90acffe4e
commit
e1b73ab93b
|
|
@ -0,0 +1,181 @@
|
|||
..
|
||||
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. File a story in StoryBoard
|
||||
(https://storyboard.openstack.org/#!/project/989). 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
|
||||
|
||||
======================
|
||||
Multiple Cloud support
|
||||
======================
|
||||
|
||||
Include the URL of your story in StoryBoard:
|
||||
|
||||
https://storyboard.openstack.org/#!/story/2002126
|
||||
|
||||
To allow Orchestration service to orchestrate cross OpenStack environment.
|
||||
This spec propose we support multiple OpenStack cloud orchestration.
|
||||
Use ``OS::Heat::Stack`` resource with new properties to provide credential
|
||||
information of another OpenStack environment.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Can't orchestrate cross multiple OpenStack cloud. For users who running
|
||||
applications cross multiple OpenStack clouds, this means they need to use
|
||||
other tools to run Stacks separately cross sites for same applications.
|
||||
This behavior is harmful for resource dependencies.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Implement multi-cloud support as an extension to the existing multi-region
|
||||
support. Allow operate a remote stack (from another OpenStack cloud) as a
|
||||
resource in stack from local OpenStack cloud.
|
||||
|
||||
I propose we add multi cloud support into ``OS::Heat::Stack`` and change the
|
||||
property schema for ``context``. Within context, we should adding
|
||||
following properties:
|
||||
|
||||
* cloud_provider: A name of a cloud provider.
|
||||
* cloud_provider_credential: ID of Barbican Secret. Which stores authN
|
||||
information for provider in remote cloud.
|
||||
* credential: ID of Barbican Secret. Which stores authN information
|
||||
for user in remote cloud.
|
||||
|
||||
Here is the example template looks like:
|
||||
|
||||
resources:
|
||||
remote_stack:
|
||||
type: OS::Heat::Stack
|
||||
properties:
|
||||
context:
|
||||
region_name: RegionOne
|
||||
cloud_provider: openstack_1
|
||||
cloud_provider_credential: {Secret_ID_For_Access_to_Remote_Cloud}
|
||||
credential: {Your_Barbican_Secret_ID}
|
||||
template: { get_file: remote_template.yaml }
|
||||
timeout: 60
|
||||
parameters:
|
||||
name: foo
|
||||
|
||||
With ``cloud_provider`` property, All cloud general information will be
|
||||
fetched from clouds.yaml/secure.yaml file under ``~/.config/openstack/``,
|
||||
``/etc/openstack``, or current working directory for heat-engine servcie
|
||||
(please see [1] for more information).
|
||||
|
||||
So user can just provide cloud name with ``cloud_provider`` property and heat
|
||||
service will fetch authentication information based on that provider name.
|
||||
|
||||
With ``cloud_provider_credential`` property, All cloud general information will
|
||||
be fetched from Barbican secret. Must only provide either one of
|
||||
``cloud_provider`` or ``cloud_provider_credential``.
|
||||
|
||||
|
||||
``OS::Heat::Stack`` will use above authN info (loaded with ``cloud_provider``,
|
||||
or ``cloud_provider_credential``). to access a remote Orchestration service.
|
||||
Once remote Orchestration service start to create stack. It will first
|
||||
refresh context with ``credential`` we provided (if any).
|
||||
|
||||
If we didn't provide ``credential`` property, the provider authN info will be
|
||||
used for the rest of process (to create and manage resource).
|
||||
|
||||
A credential is a Barbican Secret ID. We not recomanded to use entire secret
|
||||
href since it contains URL of Barbican service hance we don't support it as
|
||||
value. In secret, the secret payload must content a string which contain a json
|
||||
format dictionary. In dictionary, contains following keys:
|
||||
|
||||
* auth: a dictionary to store authentication information.(It's same
|
||||
configuration way as in clouds.yaml, see [1] and [2] for more detail on
|
||||
format)
|
||||
* auth_type: A string to show auth_type of above auth info (see [2] for more
|
||||
information).
|
||||
* roles: A list of roles to access with.
|
||||
* project_id: project id to access with.
|
||||
|
||||
Here is an example string format:
|
||||
"{
|
||||
'auth_type': 'v3applicationcredential',
|
||||
'auth': {'auth_url': 'http://192.168.1.101/identity/v3',
|
||||
'application_credential_id': '9dfa187e5a354484bf9c49a2b674333a',
|
||||
'application_credential_secret': 'sec'},
|
||||
'roles': ['admin'],
|
||||
'project_id': '8758abeaece340cfa728814101cf3c51'}"
|
||||
|
||||
User must make sure information from that credential are usable to
|
||||
authentication and generate trusts. Once context been refreshed, context in
|
||||
remote side is now contains real user authentication information which user
|
||||
would like to use to manage and operate the remote stack.
|
||||
|
||||
Credential will be stored when create stack(by remote stack resource), and
|
||||
can be replaced when update stack with credential. For non-create stack
|
||||
actions, Stack will try to find credential from DB and refresh context with
|
||||
it if founded. And it will be removed from DB, when remote stack is deleted.
|
||||
|
||||
Must make sure the authentication information from cloud provider must be able
|
||||
to access to Orchestration service and able to get that credential (ID of
|
||||
secret) from Barbican service if we also going to use ``credential``. Also for
|
||||
security concerns, it will be better to make sure only allowed user to be able
|
||||
to get that credential.
|
||||
|
||||
Because there might be a potential cross version compatibility issue, try to
|
||||
run same version of code in two OpenStack cloud or to test your environment
|
||||
with exactally what you're going to run on it.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
One can manually or use external tools to talk to multiple clouds and operate
|
||||
with it, but have to take care dependencies cross multiple sites by themself.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Rico Lin <ricolin, rico.lin@easystack.cn>
|
||||
Zane Bitter <zaneb, zbitter@redhat.com>
|
||||
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion:
|
||||
rocky-rc1
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add Stack Credential DB schema
|
||||
|
||||
* Add Stack Credential Object
|
||||
|
||||
* Support to check and replace context with stack credential
|
||||
|
||||
* Support ``OS::Heat::Stack`` to access Orchestration service from another OpenStack
|
||||
|
||||
* Add functional test
|
||||
|
||||
* Document the guideline and releasenote.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Descussion in PTG: https://etherpad.openstack.org/p/ptg-rocky-multi-cloud
|
||||
|
||||
Implementation:
|
||||
https://review.openstack.org/#/q/topic:bp/multiple-cloud-support+(status:open+OR+status:merged)
|
||||
|
||||
|
||||
[1] https://docs.openstack.org/python-openstackclient/latest/configuration/index.html#clouds-yaml
|
||||
[2] https://docs.openstack.org/keystoneauth/latest/plugin-options.html
|
||||
Loading…
Reference in New Issue