Add multiple OpenStack cloud support
Story: #2002126 Task: #22578 Change-Id: I3dbbf558290e144f649a740507747ac31dfc8b8c
This commit is contained in:
ricolin
parent
8e865c99e9
commit
681696cee7
|
|
@ -65,6 +65,14 @@ Queens
|
|||
|
||||
specs/queens/*
|
||||
|
||||
Rocky
|
||||
------
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/rocky/*
|
||||
|
||||
Backlog
|
||||
-------
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -0,0 +1,157 @@
|
|||
..
|
||||
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 separatly cross sites for same applications.
|
||||
This behavior is harmful for resource dependencies.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Implement multiple cloud 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.
|
||||
* credential: href 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
|
||||
credential: {Your_Barbican_Secret_href}
|
||||
template: { get_file: remote_template.yaml }
|
||||
timeout: 60
|
||||
parameters:
|
||||
name: foo
|
||||
|
||||
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 base on that provider name.
|
||||
``OS::Heat::Stack`` will use that authN info. 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).
|
||||
|
||||
A credential is a Barbican Secret href. 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.
|
||||
|
||||
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.
|
||||
|
||||
To allow OS::Heat::Stack to access remote stack from another OpenStack
|
||||
provider. Both properties ``cloud_provider`` and ``credential`` must be
|
||||
provided. Also must make sure the authentication information from cloud
|
||||
provider must be able to access to Orchestration service and able to get
|
||||
that credential (herf of secret) from Barbican service. 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 protential cross version compatibility issue, we can't
|
||||
guarantee the communication cross two heat sides always wroks. The only two
|
||||
ways to certified are 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. We should
|
||||
document this notice down somewhere so operators get better knowledge.
|
||||
|
||||
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 sides 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
|
||||
|
||||
|
||||
[1] https://docs.openstack.org/python-openstackclient/latest/configuration/index.html#clouds-yaml
|
||||
[2] https://docs.openstack.org/keystoneauth/latest/plugin-options.html
|
||||
|
|
@ -0,0 +1 @@
|
|||
../templates/rocky-template.rst
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
..
|
||||
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
|
||||
|
||||
===========================
|
||||
The title of your blueprint
|
||||
===========================
|
||||
|
||||
Include the URL of your story in StoryBoard:
|
||||
|
||||
https://storyboard.openstack.org/#!/story/$STORY_ID
|
||||
|
||||
Introduction paragraph -- why are we doing anything?
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
A detailed description of the problem.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Here is where you cover the change you propose to make in detail. How do you
|
||||
propose to solve this problem?
|
||||
|
||||
If this is one part of a larger effort make it clear where this piece ends. In
|
||||
other words, what's the scope of this effort?
|
||||
|
||||
Include where in the heat tree hierarchy this will reside.
|
||||
|
||||
If your specification proposes any changes to the Heat REST API such
|
||||
as changing parameters which can be returned or accepted, or even
|
||||
the semantics of what happens when a client calls into the API, then
|
||||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
This is an optional section, where it does apply we'd just like a demonstration
|
||||
that some thought has been put into why the proposed approach is the best one.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Who is leading the writing of the code? Or is this a blueprint where you're
|
||||
throwing it out there to see who picks it up?
|
||||
|
||||
If more than one person is working on the implementation, please designate the
|
||||
primary author and contact.
|
||||
|
||||
Primary assignee:
|
||||
Name <email> or None
|
||||
|
||||
Can optionally can list additional ids if they intend on doing
|
||||
substantial implementation work on this blueprint.
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion:
|
||||
rocky-1
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Work items or tasks -- break the feature up into the things that need to be
|
||||
done to implement it. Those parts might end up being done by different people,
|
||||
but we're mostly trying to understand the timeline for implementation.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
- Include specific references to specs and/or blueprints in heat, or in other
|
||||
projects, that this one either depends on or is related to.
|
||||
|
||||
- Does this feature require any new library dependencies or code otherwise not
|
||||
included in OpenStack? Or does it depend on a specific version of library?
|
||||
Loading…
Reference in New Issue