Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat"

Latest revision as of 10:29, 21 July 2014

--bartosz-gorski (talk) 23:51, 15 July 2013 (UTC)

Overview

Introduction

Most of enterprises are focusing on Multi-cloud (using both private and public clouds) as enterprise cloud strategy. They will not completely migrate to Service Provider's cloud (public cloud). They will still keep their mission critical information assets to their premise or collocation space (private cloud).

Our goal is to create Hybrid-cloud (combination of public and private cloud). Creating Hybrid-cloud requires:

Seamless operation among heterogeneous environment
End-to-end automatic provisioning based on system template (VM, network, topology)
Unified control and monitoring
- Multi-Hypervisor including bare-metal
- Multi-Region control
- Secure network access via Internet (VPN connection)

Hybrid-cloud

Requirements

Requirements for Heat:

mapping between Regions and API endpoints (multi-region keystone catalog)
mapping between Regions and Images (Mapping section inside template)
specifying region for resource
support for VPN as resource
support dependencies between resource in different regions
horizon interface for Heat with multi regions

Goal

Multi region first use case

First Use Case Scenario (no dependencies)

We have two regions (RegionOne and RegionTwo) with separate OpenStack installations. We want to use Heat with multi region support to create in both regions:

Neutron Network
Neutron Subnet
- 10.1.0.0/24 in RegionOne
- 10.2.0.0/24 in RegionTwo
Router
- Router Interface for created subnet
- Router Gateway for external network
VPN Service for created router
- IKE Policy
- IPsec Policy
- VPN Connection
Server connected to created subnet

Created servers should be able to see each other using local IP address.

First_Use_Case.template - template file for it in appendix.

Second Use Case Scenario (with dependencies)

Similar to the first use case but creation of the second server depends on the first one. We want to deploy web service (ex. wordpress) on two servers. One server with application (ex. apache and wordpress) and second server with database (ex. mysql server). Befor creating server with application we need to know the IP address of the server with database so we need to wait until it will be created.

Second_Use_Case.template - template file for it in appendix.

Architecture

Overview

Components Diagram

Description:

more than one region (for example two: RegionOne and RegionTwo)
separate OpenStack installation (Nova, Glance, Swift, Neutron and Cinder) in each region
one Keystone service for all regions
one Horizon with multi region support
two Heat services (one in each region) which can create remote resources in other regions

First solution

Currently Heat launches the stack using context which includes:

keystone endpoint
tenant/project
user credentials

We will add possibility to represent the context as a template resources. This will allow us to specify for other resources which context to provision within. This soultion is more generic than multi-region because because we will be able not only specify different region but also different user credentials or tenant.

In the first version of the proposed solution we will only allow to specify different context for nested stacks.

Challenges & Problems

Challenge	Solution
How to represent credentials for different clouds?	?
How to avoid single point of failure (HA)?	?
What is the better way to pass template file for nested stack than url to file?	?
What should happen if one of the region fails?	?

What needs to be done

Heat

Engine

VPN support

Blueprint for VPaaS support

Nested Stack

Property	Description
context	Context which will be used to create nested stack
-> tenant_name	Name of the keystone project.
-> region_name	Name of the region.
-> username	Username of the keystone account.
-> password	Password for provided username.
-> auth_url	URL to the authentication service.
template	nested stack template file
timeout	Creation timeout in minutes
parameters	Values for nested stack parameters

...
resources :
    ...
    NewStackTemplate:
        type: OS::Heat::Stack
        properties:
            template: { get_file: NestedStack.yaml }
            context:
                tenant_name : demo
                region_name: RegionOne
                username: { get_param: username }
                password: { get_param: password }
            parameters:
                parameter_name1: value_1
                parameter_name2: value_2
                parameter_name3: value_3
                ...
    ...
...

UI

Existing UI views:

What about views for nested stack?

Horizon support for multi regions

Dropbox will appear only if more than one region is available in keystone catalog.

Project Tab
- Dropbox to choose one of the available regions (Horizon Multi Region Project Tab)
Admin Tab
- Dropbox to choose one of the available regions (Horizon Multi Region Admin Tab)

Dependencies & References

BL: Implement a Heat UI for managing stacks (MERGED)
- Patch
BL: Support multiple endpoints for the same service (MERGED)
- Patch
BL: VPN as a Service providing IPsec VPN with Static routing (UNDER REVIEW)
Getting gateway IP address for created neutron router inside the template file [NOT SUPPORTED RIGHT NOT - MISSING FEATURE]

Appendix

Etherpad from IceHouse design summit session

Templates

Github repository with templates

First_Use_Case.template
Second_USe_Case.template

POC version

NTTI3

@@ Line 15: / Line 15: @@
 [[File:Multi Region Heat.png|800x525px|framed|center|Hybrid-cloud]]
-=== Requirements & Challenges ===
+=== Requirements ===
 Requirements for Heat:
-* Mapping between Regions and API endpoints
+* mapping between Regions and API endpoints (multi-region keystone catalog)
-* Mapping between Regions and Images
+* mapping between Regions and Images (Mapping section inside template)
-* Specifying Region for each resource
+* specifying region for resource
-* Support for VPN as resource
+* support for VPN as resource
-* Horizon interface for Heat with multi regions
+* support dependencies between resource in different regions
+* horizon interface for Heat with multi regions
-Challenges:
-* how to avoid single point of failure?
-* what is the better way to pass template file for nested stack than url to file?
 === Goal ===
@@ Line 35: / Line 31: @@
 ==== First Use Case Scenario (no dependencies) ====
-We have two regions (East and West) with separate OpenStack installations. We want to use Heat with multi region support to create in both regions:
+We have two regions (RegionOne and RegionTwo) with separate OpenStack installations. We want to use Heat with multi region support to create in both regions:
-* Quantum Network
+* Neutron Network
-* Quantum Subnet
+* Neutron Subnet
-** 10.1.0.0/24 in East
+** 10.1.0.0/24 in RegionOne
-** 10.2.0.0/24 in West
+** 10.2.0.0/24 in RegionTwo
 * Router
 ** Router Interface for created subnet
@@ Line 64: / Line 60: @@
 Description:
-* More than one region (for example two: East and West)
+* more than one region (for example two: RegionOne and RegionTwo)
-* Separate OpenStack installation (Nova, Glance, Swift, Neutron and Cinder) in each region
+* separate OpenStack installation (Nova, Glance, Swift, Neutron and Cinder) in each region
-* One Keystone service for all regions
+* one Keystone service for all regions
-* One Horizon with multi region support
+* one Horizon with multi region support
+* two Heat services (one in each region) which can create remote resources in other regions
+=== First solution ===
+Currently Heat launches the stack using context which includes:
+* keystone endpoint
+* tenant/project
+* user credentials
-==== Stack Launch Flow ====
-Multi region template (master template) is the main template file that is sent to the heat engine in one of the available regions. It consists of two types of resources:
+We will add possibility to represent the context as a template resources. This will allow us to specify for other resources which context to
-* '''local resource''' (resource without specified context) - can be a single resource or nested stack and it will be created with default context (with the same region, project and user credentails that master template was launched).
+provision within. This soultion is more generic than multi-region because because we will be able not only specify different region but also different user credentials or tenant.
-* '''remote resource''' (with specified context) - can be only a nested stack and it will be created by sending the template to appopriate heat engine in specified region.
-[[File:Template flow.png|800x419px|framed|center|Template flow]]
+In the first version of the proposed solution we will only allow to specify different context for nested stacks.
-==== Challenges & Solutions ====
+=== Challenges & Problems ===
 {| class="wikitable"
 |-
-! Challenge !! First step !! Future work
+! Challenge !! Solution
+|-
+| How to represent credentials for different clouds? || ?
+|-
+| How to avoid single point of failure (HA)? || ?
+|-
+| What is the better way to pass template file for nested stack than url to file? || ?
+|-
+| What should happen if one of the region fails? || ?
 |-
-| Dependencies between resources from different regions. || ||
 |}
@@ Line 93: / Line 102: @@
 [[Heat/Blueprints/VPaaS_Support|Blueprint for VPaaS support]]
-==== Context as Resource ====
+==== Nested Stack ====
 {| class="wikitable"
@@ Line 99: / Line 108: @@
 ! Property !! Description
 |-
-| name || User friendly name of the context
+| context || Context which will be used to create nested stack
-|-
-| description || Context description.
-|-
-| project_name || Name of the keystone project.
 |-
-| region_name || Name of the region.
+| -> tenant_name || Name of the keystone project.
 |-
-| heat_endpoint || URL to the Heat API in specified region. If not provided Heat will query keystone service to get it.
+| -> region_name || Name of the region.
 |-
-| username || Username of the keystone account.
+| -> username || Username of the keystone account.
-|-
-| password || Password for provided username.
-|-
-|}
-<pre><nowiki>
-...
-"Resources" : {
-    ...
-    "MyContext": {
-        "Type": "OS::Cloud::Context",
-        "Properties": {
-            "name": "My context",
-            "descirption": "My new context description",
-            "project_name" : "demo",
-            "region_name" : "RegionOne",
-            "username" : { "Ref" : "Username" },
-            "password" : { "Ref" : "Password" }
-        }
-    },
-    ...
-}
-...
-</nowiki></pre>
-==== Nested Stack ====
-{| class="wikitable"
 |-
-! Property !! Description !! Implementation
+| -> password || Password for provided username.
 |-
-| Context || Context which will be used to create nested stack || '''Not started'''
+| -> auth_url || URL to the authentication service.
 |-
-| TemplateURL || Url address to nested stack tempalte file  || Done
+| template ||  nested stack template file
 |-
-| TimeoutInMinutes || Creation timeout in minutes || Done
+| timeout || Creation timeout in minutes
 |-
-| Parameters || Values for nested stack parameters || Done
+| parameters || Values for nested stack parameters
 |-
 |}
@@ Line 153: / Line 130: @@
 <pre><nowiki>
 ...
-"Resources" : {
+resources :
      ...
-     "NewStackTemplate": {
+     NewStackTemplate:
-         "Type": "AWS::CloudFormation::Stack",
+         type: OS::Heat::Stack
-         "Properties": {
+         properties:
-             "TemplateURL": "https://raw.github.com/openstack/heat-templates/master/cfn/NestedStack.template",
+             template: { get_file: NestedStack.yaml }
-             "Parameters": {
+             context:
-                 "ParameterName1" : "Value1",
+                tenant_name : demo
-                 "ParameterName2" : "Value2",
+                region_name: RegionOne
-                 "ParameterName3" : "Value3",
+                username: { get_param: username }
+                password: { get_param: password }
+            parameters:
+                 parameter_name1: value_1
+                 parameter_name2: value_2
+                 parameter_name3: value_3
                  ...
-            }
-        }
-    },
      ...
-}
 ...
 </nowiki></pre>
@@ Line 182: / Line 160: @@
 ** [https://wiki.openstack.org/wiki/File:Heat_ui_stack_detail_events_tab.png Events Tab]
 * [https://wiki.openstack.org/wiki/File:Heat_ui_resource_detail.png Resource Details]
 What about views for nested stack?
@@ Line 205: / Line 184: @@
 ** [https://review.openstack.org/#/c/29811/ API Patch]
 ** [https://wiki.openstack.org/wiki/Quantum/VPNaaS/HowToInstall Instruction]
+* Getting gateway IP address for created neutron router inside the template file [NOT SUPPORTED RIGHT NOT - MISSING FEATURE]
 == Appendix ==
+[https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud Etherpad from IceHouse design summit session]
 === Templates ===
+[https://github.com/hanney/mr-heat-templates Github repository with templates]
+* First_Use_Case.template
+* Second_USe_Case.template
-* Multiregion.template
+=== POC version ===
-<pre><nowiki>
-</nowiki></pre>
+* [https://review.openstack.org/#/c/53313/ Patch with proof of concept version]
+* [http://www.youtube.com/watch?v=kXOVoRWixu8 Live demo]
 [[File:Ntti3 logo.png|framed|center|NTTI3]]

Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat"

Latest revision as of 10:29, 21 July 2014

Contents

Overview

Introduction

Requirements

Goal

First Use Case Scenario (no dependencies)

Second Use Case Scenario (with dependencies)

Architecture

Overview

First solution

Challenges & Problems

What needs to be done

Heat

Engine

VPN support

Nested Stack

UI

Horizon support for multi regions

Dependencies & References

Appendix

Templates

POC version