Jump to: navigation, search

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

(→‎Nested Stack)
 
(100 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
--[[User:Hanney|bartosz-gorski]] ([[User talk:Hanney|talk]]) 23:51, 15 July 2013 (UTC)
 
== Overview ==
 
== Overview ==
 
=== Introduction ===
 
=== Introduction ===
Line 12: Line 13:
 
** Secure network access via Internet (VPN connection)
 
** Secure network access via Internet (VPN connection)
  
−
[[File:Multi Region Heat.png|framed|Multi Region Heat]]
+
[[File:Multi Region Heat.png|800x525px|framed|center|Hybrid-cloud]]
  
−
=== Requirements & Challenges ===
+
=== Requirements ===
  
 
Requirements for Heat:
 
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
  
 +
=== Goal ===
  
−
Challenges:
+
[[File:Multi region first use case.png|800x416px|framed|center|Multi region first use case]]
−
* dealing with dependencies between resources in different regions
 
−
* minimizing number of single region templates for which multi region template will be split
 
−
* figure out efficient way to update multi region stack
 
−
 
 
−
=== Goal ===
 
−
==== Basic Use Case Scenario ====
 
  
−
[[File:Multi region first use case.png|framed|Multi region first use case]]
+
==== 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
 
** Router Interface for created subnet
 
** Router Interface for created subnet
Line 48: Line 45:
 
* Server connected to created subnet
 
* 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.
  
−
Template file example in appendix.  
+
'''Second_Use_Case.template''' - template file for it in appendix.  
  
 
=== Architecture ===
 
=== Architecture ===
 
==== Overview ====
 
==== Overview ====
−
[[File:Components Diagram.png|framed|Components Diagram]]
+
[[File:Components Diagram.png|800x600px|framed|center|Components Diagram]]
  
 
Description:
 
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
−
* One Heat for multi region orchestration - to be clear right now it does not exist
+
* two Heat services (one in each region) which can create remote resources in other regions
  
−
==== Template Flow ====
+
=== First solution ===
−
[[File:Template flow.png|framed|Template flow]]
 
−
==== Challenges & Solutions ====
 
  
−
{| class="wikitable"
+
Currently Heat launches the stack using context which includes:
−
|-
+
* keystone endpoint
−
! Challenge !! First step !! Future work
+
* tenant/project
−
|-
+
* user credentials
−
| Dependencies between resources from different regions. || There will be not such dependencies and we do not need to deal with them. || Multi region Heat component will be responsible for dealing with dependencies and creation order (needs to create dependencies graph where each node is a single region template).
 
−
|-
 
−
| Amount of single region templates. || Only one template for each region containing all resources from that region. It is possible because there is not dependencies between regions. || Decreasing number of templates by putting independent resources to the same template (assuming we have dependencies between resources from different regions).
 
−
|-
 
−
| Update stack || Silly update (Delete old and Create new) || More efficient update.
 
−
|}
 
−
 
 
−
== What needs to be done ==
 
−
=== Heat ===
 
−
==== Engine ====
 
  
−
Adding new resources types:
 
−
* VPNServices
 
−
* IKEPolicy
 
−
* IPsecPolicy
 
−
* VPNConnections
 
  
−
===== VPNServices =====
+
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.
  
−
{| class="wikitable"
+
In the first version of the proposed solution we will only allow to specify different context for nested stacks.
−
|-
 
−
! Property !! Description
 
−
|-
 
−
| name || Name of the VPN Service.
 
−
|-
 
−
| description || Description of the VPN Service.
 
−
|-
 
−
| admin_state_up || Administrative state of vpnservice. If false (down), port does not forward packets.
 
−
|-
 
−
| subnet_id || Subnet id in which the tenant wants the vpn service.
 
−
|-
 
−
| router_id || Router id to which the vpn service is inserted.
 
−
|}
 
  
−
Example:
+
=== Challenges & Problems ===
−
 
 
−
<pre><nowiki>
 
−
...
 
−
"Resources" : {
 
−
    ...
 
−
    "VPNService" : {
 
−
        "Type" : "OS::Quantum::VPNService",
 
−
        "Properties" : {
 
−
            "Name" : "MyVPN",
 
−
            "Description" : "My new VPN",
 
−
            "AdminStateUP" : True,
 
−
            "SubnetId" : { "Ref" : "Subnet" },
 
−
            "RouterId" : { "Ref" : "Router" }
 
−
    }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
−
 
 
−
===== IKEPolicy =====
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Property !! Description
+
! Challenge !! Solution
−
|-
 
−
| name || Friendly name for the IKE policy.
 
−
|-
 
−
| description || Description of the IKE policy.
 
−
|-
 
−
| auth_algorithm || Authentication Hash algorithms "sha1".
 
 
|-
 
|-
−
| encryption_algorithm || Encryption Algorithms 3des, aes-128, aes-256, aes-192 etc.
+
| How to represent credentials for different clouds? || ?
 
|-
 
|-
−
| phase1_negotiation_mode || IKE mode "main".
+
| How to avoid single point of failure (HA)? || ?
 
|-
 
|-
−
| lifetime_units || Lifetime of the  SA unit in "seconds" or "kilobytes".
+
| What is the better way to pass template file for nested stack than url to file? || ?
 
|-
 
|-
−
| lifetime_value || Lifetime value in seconds or kilobytes.
+
| What should happen if one of the region fails? || ?
 
|-
 
|-
−
| pfs || Perfect Forward Secrecy  (group2, group5, group14).
 
−
|-
 
−
| ike_version || v1 or v2 version.
 
 
|}
 
|}
  
−
Example:
+
== What needs to be done ==
 +
=== Heat ===
 +
==== Engine ====
  
−
<pre><nowiki>
+
===== VPN support =====
−
...
+
[[Heat/Blueprints/VPaaS_Support|Blueprint for VPaaS support]]
−
"Resources" : {
 
−
    ...
 
−
    "IKEPolicy" : {
 
−
        "Type" : "OS::Quantum::IKEPolicy",
 
−
        "Properties" : {
 
−
            "Name" : "MyIKEPolicy",
 
−
            "Description" : "My new IKE policy",
 
−
            "AuthAlgorithm" : "sha1",
 
−
            "EncryptionAlgorithm" : "3des",
 
−
            "Phase1NegotiationMode" : "main",
 
−
            "LifetimeUnits" : "seconds",
 
−
            "LifetimeValue" : 3600,
 
−
            "PFS" : "group5",
 
−
            "IKEVersion" : "v1",
 
−
    }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
  
−
===== IPsecPolicy =====
+
==== Nested Stack ====
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 179: Line 108:
 
! Property !! Description
 
! Property !! Description
 
|-
 
|-
−
| name || Friendly name for the IPsec policy.
+
| context || Context which will be used to create nested stack
 
|-
 
|-
−
| description || Description of the IPsec policy.
+
| -> tenant_name || Name of the keystone project.
 
|-
 
|-
−
| transform_protocol || Transform Protocol used such as "esp" or "ah" or "ah-esp".
+
| -> region_name || Name of the region.
 
|-
 
|-
−
| encapsulation_mode || Encapsulation mode either "tunnel" mode or "transport" mode.
+
| -> username || Username of the keystone account.
 
|-
 
|-
−
| auth_algorithm || Authentication Hash algorithms "sha1".
+
| -> password || Password for provided username.
 
|-
 
|-
−
| phase1_negotiation_mode || IKE mode "main".
+
| -> auth_url || URL to the authentication service.
 
|-
 
|-
−
| lifetime_units || Lifetime of the SA unit in "seconds" or "kilobytes".
+
| template ||  nested stack template file
 
|-
 
|-
−
| lifetime_value || Lifetime value in seconds or kilobytes.
+
| timeout || Creation timeout in minutes
 
|-
 
|-
−
| pfs || Perfect Forward Secrecy  (group2, group5, group14).
+
| parameters || Values for nested stack parameters
−
|}
 
−
 
 
−
Example:
 
−
 
 
−
<pre><nowiki>
 
−
...
 
−
"Resources" : {
 
−
    ...
 
−
    "IPsecPolicy" : {
 
−
        "Type" : "OS::Quantum::IPsecPolicy",
 
−
        "Properties" : {
 
−
            "Name" : "MyIKEPolicy",
 
−
            "Description" : "My new IKE policy",
 
−
            "EncapsulationMode" : "tunnel",
 
−
            "AuthAlgorithm" : "3des",
 
−
            "LifetimeUnits" : "seconds",
 
−
            "LifetimeValue" : 3600,
 
−
            "PFS" : "Group5"
 
−
    }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
−
 
 
−
===== VPNConnections =====
 
−
 
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! Property !! Description
 
−
|-
 
−
| name || Friendly Name for the VPN connection.
 
−
|-
 
−
| description || Description of the VPN connection.
 
−
|-
 
−
| peer_address || Peer VPN gateway public address or FQDN.
 
−
|-
 
−
| peer_id || Peer identifier (Can be name, string or FQDN).
 
−
|-
 
−
| mtu || Maximum transmission unit to address fragmentation.
 
−
|-
 
−
| dpd_actions || DPD actions controls the use of Dead Peer Detection Protocol. ("clear", "hold", "restart", "disabled", "restart-by-peer").
 
−
|-
 
−
| dpd_interval || Number of seconds for DPD delay.
 
−
|-
 
−
| dpd_timeout || Number of seconds for DPD timeout.
 
−
|-
 
−
| psk || Pre-shared-key any string.
 
−
|-
 
−
| initiator || Whether this VPN can only respond to connections or can initiate as well.
 
−
|-
 
−
| admin_state_up || Administrative state of vpn connection. If false (down), VPN connection does not forward packets.
 
−
|-
 
−
| ikepolicy_id || UUID id of IKE policy.
 
−
|-
 
−
| ipsecpolicy_id || UUID id of IPsec policy.
 
−
|-
 
−
| vpnservice_id || UID id of VPN service.
 
 
|}
 
|}
−
 
−
Example:
 
  
 
<pre><nowiki>
 
<pre><nowiki>
 
...
 
...
−
"Resources" : {
+
resources :
 
     ...
 
     ...
−
     "VPNConnection" : {
+
     NewStackTemplate:
−
         "Type" : "OS::Quantum::VPNConnection",
+
         type: OS::Heat::Stack
−
         "Properties" : {
+
         properties:
−
             "Name" : "MyVPNConnection",
+
             template: { get_file: NestedStack.yaml }
−
            "Description" : "My new VPN connection",
+
             context:
−
            “PeerAddress” : "10.0.0.1",
+
                tenant_name : demo
−
             "PeerId" : "peer",
+
                region_name: RegionOne
−
            "PeerCidrs" : ["10.0.0.0/24"],
+
                username: { get_param: username }
−
            "RouteMode" : "static",
+
                password: { get_param: password }
−
            "mtu" : "1500",
+
             parameters:
−
            "DpdActions" : "hold",
+
                parameter_name1: value_1
−
            "DpdInterval" : "30",
+
                parameter_name2: value_2
−
            "DpdTimeout" : "120",
+
                parameter_name3: value_3
−
             "AuthMode" : "psk",
+
                ...
−
            "Psk" : "secret",
 
−
            "Initiator" : "bi-directional",
 
−
            "AdminStateUp" : "Yes",
 
−
            "IKEPolicyId" : { "Ref" : "ike_policy" },
 
−
            "IPsecPolicyId" : { "Ref” : "ipsec_policy" },
 
−
            "VPNServiceId" : { "Ref" : "vpn_service" },
 
−
    }
 
 
     ...
 
     ...
−
},
 
 
...
 
...
 
</nowiki></pre>
 
</nowiki></pre>
−
 
−
==== API/CLI ====
 
−
 
−
Probably we do not need to add any new command.
 
  
 
==== UI ====
 
==== UI ====
  
 
Existing UI views:
 
Existing UI views:
−
* Stack List for Tenant
+
* [https://wiki.openstack.org/wiki/File:Heat_ui_stacks.png Stack List for Tenant]
−
* Launch new Stack
+
* [https://wiki.openstack.org/wiki/File:Heat_ui_launch_stack.png Launch new Stack ]
 
* Stack Details
 
* Stack Details
−
** Overview tab
+
** [https://wiki.openstack.org/wiki/File:Heat_ui_stack_detail_overview_tab.png Overview Tab]
−
** Resources tab
+
** [https://wiki.openstack.org/wiki/File:Heat_ui_stack_detail_resources_tab.png Resources Tab]
−
** Events tab
+
** [https://wiki.openstack.org/wiki/File:Heat_ui_stack_detail_events_tab.png Events Tab]
−
* Resource Details
+
* [https://wiki.openstack.org/wiki/File:Heat_ui_resource_detail.png Resource Details]
  
−
=== Multi region Heat [DRAFT - WORK IN PROGRESS] ===
 
−
==== Engine ====
 
  
−
Representing Multi region stack:
+
What about views for nested stack?
−
* Raw template
 
−
* Region names list
 
−
* Mapping between stack and region
 
−
* Mapping between resource and stack
 
−
* List of Single Stacks data
 
−
** (region_name, single_region_template, single_region_stack_id)
 
  
−
===== Mapping regions with API endpoints [SUPPORTED] =====
+
=== Horizon support for multi regions ===
  
−
Concerns:
+
Dropbox will appear only if more than one region is available in keystone catalog.
−
* maybe we can get those information from Keystone?
 
−
* what about multi endpoints for one region?
 
−
 
 
−
Example:
 
−
<pre><nowiki>
 
−
...
 
−
"Mappings" : {
 
−
    ...
 
−
        "Region2EndPoints" : {
 
−
            "East"  : { "orchestration" : "orchestration.east.openstack.com"},
 
−
            "West" : { "orchestration" : “orchestration.west.openstack.com"}
 
−
        }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
−
 
 
−
===== Mapping regions with images [SUPPORTED] =====
 
−
 
 
−
Example:
 
−
<pre><nowiki>
 
−
...
 
−
"Mappings" : {
 
−
    ...
 
−
    "Region2Image" : {
 
−
        "East" : { "F17" : "F17-x86_64-cfntools", "U12" : "ubuntu-vm-heat-cfntools" },
 
−
        "West" : { "F17" : "F17-x86_64-cfntools", "U12" : "ubuntu-vm-heat-cfntools" }
 
−
    }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
−
 
 
−
===== Specify RegionName property for resource [NOT SUPPORTED] =====
 
−
 
 
−
Example:
 
−
<pre><nowiki>
 
−
...
 
−
"Resources" : {
 
−
    ...
 
−
    "Ec2Instance" : {
 
−
        "Type" : "AWS::EC2::Instance",
 
−
        '''"RegionName" : { "Ref" : "RegionName" },'''
 
−
        "Properties" : {
 
−
            "ImageId" : { "Ref" : "ImageId" },
 
−
            "KeyName" : { "Ref" : "KeyName" },
 
−
            "InstanceType" : { "Ref" : "InstanceType" }
 
−
            "SubnetId" : { "Ref" : "SubnetWest" }
 
−
    }
 
−
    ...
 
−
},
 
−
...
 
−
</nowiki></pre>
 
−
 
 
−
==== API/CLI ====
 
−
 
 
−
Should provide the same API functionalities as single region Heat API:
 
−
* Events
 
−
** event-list - List events for a stack.
 
−
*** querying each region API with event-list request
 
−
*** aggregating results and sorting events by date
 
−
** event-show - Describe the event
 
−
*** querying each region API with event-show request to find it
 
−
* Resources
 
−
** resource-list - Show list of resources belonging to a stack
 
−
*** querying each region API with resource-list request and aggregating results
 
−
** resource-metadata - List resource metadata
 
−
*** checking in which region given resource was created and querying it API for result
 
−
** resource-show - Describe the resource
 
−
*** checking in which region given resource was created and querying it API for result
 
−
* Stacks
 
−
** stack-create - Create the stack
 
−
*** parsing multi region template and creating set of single region templates
 
−
*** creating stack for each single region template in specified region
 
−
** stack-delete - Delete the stack
 
−
*** getting list of single stack ids and for each one querying appropriate region API to delete it
 
−
** stack-update - Update the stack
 
−
*** dummy update
 
−
**** deleting old multi region stack
 
−
**** creating new multi region stack for new template
 
−
** stack-list - List the user's stacks
 
−
*** returning list of created multi region stacks
 
−
** stack-show - Describe the stack
 
−
*** querying each region API with stack-show request for each single region stack
 
−
*** aggregating results
 
−
* Templates
 
−
** template-show - Get the template for the specified stack
 
−
*** returning multi region template
 
−
** template-validate - Validate a template with parameters
 
−
*** validating whole multi region template
 
−
 
 
−
==== UI ====
 
−
 
 
−
Additional tab for multi region stack is required.
 
−
To be continue...
 
−
 
 
−
=== Horizon support for multi regions ===
 
  
 
* Project Tab  
 
* Project Tab  
−
** Dropbox to choose one of the available regions
+
** Dropbox to choose one of the available regions ([https://wiki.openstack.org/wiki/File:Horizon_multi_region_project_tab.png Horizon Multi Region Project Tab])
 
* Admin Tab
 
* Admin Tab
−
** Dropbox to choose one of the available regions
+
** Dropbox to choose one of the available regions ([https://wiki.openstack.org/wiki/File:Horizon_multi_region_admin_tab.png Horizon Multi Region Admin Tab])
−
 
 
−
Dropbox will appear only if more than one region is available in keystone catalog.
 
  
 
== Dependencies & References ==
 
== Dependencies & References ==
  
−
* BL: Implement a Heat UI for managing stacks (MERGED)
+
* BL: [https://blueprints.launchpad.net/horizon/+spec/heat-ui Implement a Heat UI for managing stacks] '''(MERGED)'''
−
** patch
+
** [https://review.openstack.org/#/c/29478/ Patch]
−
* BL: Support multiple endpoints for the same service (MERGED)
+
* BL: [https://blueprints.launchpad.net/horizon/+spec/multiple-service-endpoints Support multiple endpoints for the same service] '''(MERGED)'''
−
** patch
+
** [https://blueprints.launchpad.net/horizon/+spec/multiple-service-endpoints Patch]
−
* BL: VPN as a Service providing IPsec VPN with Static routing (UNDER REVIEW)
+
* BL: [https://blueprints.launchpad.net/neutron/+spec/quantum-vpnaas-ipsec-ssl VPN as a Service providing IPsec VPN with Static routing] '''(UNDER REVIEW)'''
−
** UI patch
+
** [https://review.openstack.org/#/c/34882/ UI Patch]
−
** backend patch
+
** [https://review.openstack.org/#/c/33148/ Backend Patch]
−
** API patch
+
** [https://review.openstack.org/#/c/29811/ API Patch]
−
** instruction
+
** [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]
  
−
== Action Plan ==
+
== Appendix ==
  
−
# Add VPNaaS to supported resources in Heat engine '''[Done]'''
+
[https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud Etherpad from IceHouse design summit session]
−
# Create template to set up one side VPN connection '''[Done]'''
 
−
# Create simple version of Multi Heat engine
 
−
* splits multi region template to set of simple region templates
 
−
* creates a stack for each single template in appropriate region
 
−
# Create multi region template to set up VPN connection between two devstacks
 
−
# Test template for first use case (the one described above)
 
−
# Add support for dependencies between resources from different regions to multi heat engine
 
  
−
== Appendix ==
 
 
=== Templates ===
 
=== Templates ===
−
=== Heat UI screenshots ===
+
[https://github.com/hanney/mr-heat-templates Github repository with templates]
−
=== Horizon Multi region support screenshots ===
+
* First_Use_Case.template
 +
* Second_USe_Case.template
 +
 
 +
=== POC version ===
 +
 
 +
* [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]]

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.

Dependencies & References

Appendix

Etherpad from IceHouse design summit session

Templates

Github repository with templates

  • First_Use_Case.template
  • Second_USe_Case.template

POC version

NTTI3
Retrieved from "https://wiki.openstack.org/w/index.php?title=Heat/Blueprints/Multi_Region_Support_for_Heat&oldid=58527"