Jump to: navigation, search

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

(Nested Stack)
 
(48 intermediate revisions by the same user not shown)
Line 15: Line 15:
 
[[File:Multi Region Heat.png|800x525px|framed|center|Hybrid-cloud]]
 
[[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 ===
 
 
==== First Use Case Scenario (no dependencies) ====
 
==== First Use Case Scenario (no dependencies) ====
  
[[File:Multi region first use case.png|800x416px|framed|center|Multi region first use case]]
+
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
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:
+
* Neutron Subnet  
* Quantum Network
+
** 10.1.0.0/24 in RegionOne
* Quantum Subnet  
+
** 10.2.0.0/24 in RegionTwo
** 10.1.0.0/24 in East
 
** 10.2.0.0/24 in West
 
 
* Router
 
* Router
 
** Router Interface for created subnet
 
** Router Interface for created subnet
Line 49: 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.
  
Template file example in appendix (Multiregion.template).  
+
'''First_Use_Case.template''' - template file for it in appendix.  
  
 
==== Second Use Case Scenario (with dependencies) ====
 
==== Second Use Case Scenario (with dependencies) ====
TBD
+
 
 +
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 ===
 
=== Architecture ===
 
==== Overview ====
 
==== Overview ====
<!-- [[File:Components Diagram.png|800x600px|framed|center|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
  
==== Context as Resource ====
+
=== 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 ===
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Property !! Description !! Default Value
+
! Challenge !! Solution
 
|-
 
|-
| Tenant/Project ||  ||  
+
| How to represent credentials for different clouds? || ?
 
|-
 
|-
| Region/Endpoint ||  ||  
+
| How to avoid single point of failure (HA)? || ?
 
|-
 
|-
| User credentails || ||  
+
| 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? || ?
 
|-
 
|-
 
|}
 
|}
  
<pre><nowiki>
+
== What needs to be done ==
...
+
=== Heat ===
"Resources" : {
+
==== Engine ====
    ...
 
    "NetworkEast": {
 
        "Type": "OS::Quantum::Net",
 
        "RegionName" : { "Ref" : "RegionEast" },
 
        "Properties": {
 
            "name": "East Region Network"
 
        }
 
    },
 
    ...
 
}
 
...
 
</nowiki></pre>
 
  
 +
===== VPN support =====
 +
[[Heat/Blueprints/VPaaS_Support|Blueprint for VPaaS support]]
  
 
==== Nested Stack ====
 
==== Nested Stack ====
Line 101: Line 106:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Property !! Description !! Default Value
+
! Property !! Description
 +
|-
 +
| context || Context which will be used to create nested stack
 +
|-
 +
| -> tenant_name || Name of the keystone project.
 
|-
 
|-
| Context ||  ||  
+
| -> region_name || Name of the region.
 
|-
 
|-
| TemplateURL ||  ||  
+
| -> username || Username of the keystone account.
 
|-
 
|-
| Parameters ||  ||  
+
| -> 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
 
|-
 
|-
 
|}
 
|}
Line 113: Line 130:
 
<pre><nowiki>
 
<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>
 
</nowiki></pre>
 
==== Master Template ====
 
 
TBD
 
 
==== Stack Launch Flow ====
 
 
<!-- [[File:Template flow.png|800x419px|framed|center|Template flow]] -->
 
 
==== Challenges & Solutions ====
 
 
{| class="wikitable"
 
|-
 
! Challenge !! First step !! Future work
 
|-
 
| Dependencies between resources from different regions. || ||
 
|}
 
 
== What needs to be done ==
 
=== Heat ===
 
==== Engine ====
 
 
[[Heat/Blueprints/VPaaS_Support|Blueprint for VPaaS support]]
 
 
==== API/CLI ====
 
 
Probably we do not need to add any new command.
 
  
 
==== UI ====
 
==== UI ====
Line 169: 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_stack_detail_events_tab.png Events Tab]
 
* [https://wiki.openstack.org/wiki/File:Heat_ui_resource_detail.png Resource Details]
 
* [https://wiki.openstack.org/wiki/File:Heat_ui_resource_detail.png Resource Details]
 +
 +
 +
What about views for nested stack?
  
 
=== Horizon support for multi regions ===
 
=== Horizon support for multi regions ===
Line 190: Line 184:
 
** [https://review.openstack.org/#/c/29811/ API Patch]
 
** [https://review.openstack.org/#/c/29811/ API Patch]
 
** [https://wiki.openstack.org/wiki/Quantum/VPNaaS/HowToInstall 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]
  
 
== Appendix ==
 
== Appendix ==
 +
 +
[https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud Etherpad from IceHouse design summit session]
  
 
=== Templates ===
 
=== 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>
 
{
 
  "AWSTemplateFormatVersion" : "2010-09-09",
 
 
 
  "Description" : "Creates VPN connection between to different regions and lanuches one server in each region",
 
 
 
  "Parameters" : {
 
 
 
    "KeyName" : {
 
      "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the instances",
 
      "Type" : "String"
 
    },
 
   
 
    "InstanceType" : {
 
      "Description" : "EC2 instance type",
 
      "Type" : "String",
 
      "Default" : "m1.small",
 
      "AllowedValues" : [ "m1.tiny", "m1.small", "m1.medium", "m1.large", "m1.xlarge" ],
 
      "ConstraintDescription" : "must be a valid EC2 instance type."
 
    },
 
   
 
    "LinuxDistribution": {
 
      "Default": "U12",
 
      "Description" : "Distribution of choice",
 
      "Type": "String",
 
      "AllowedValues" : [ "F17", "U12" ]
 
    },
 
   
 
    "RegionEast" : {
 
      "Description" : "Name of the East region",
 
      "Type" : "String",
 
      "Default" : "RegionOne",
 
      "ConstraintDescription" : "must be a existing OpenStack region"
 
    },
 
 
 
    "RegionWest" : {
 
      "Description" : "Name of the West region",
 
      "Type" : "String",
 
      "Default" : "RegionTwo",
 
      "ConstraintDescription" : "must be a existing OpenStack region"
 
    },
 
 
 
    "ExternalNetworkIdEast" : {
 
      "Description" : "External network id on East",
 
      "Type" : "String",
 
      "ConstraintDescription" : "must be a id of existing external network on East"
 
    },
 
   
 
    "ExternalNetworkIdWest" : {
 
      "Description" : "External network id on West",
 
      "Type" : "String",
 
      "ConstraintDescription" : "must be a id of existing external network on West"
 
    },
 
   
 
    "ExternalGatewayIPAddressEast" : {
 
      "Description" : "External Gateway IP address on East",
 
      "Type" : "String",
 
      "ConstraintDescription" : "must be an IP address of external gateway on East"
 
    },
 
 
 
    "ExternalGatewayIPAddressWest" : {
 
      "Description" : "External Gateway IP address on West",
 
      "Type" : "String",
 
      "ConstraintDescription" : "must be an IP address of external gateway on West"
 
    }
 
 
 
  },
 
 
 
  "Mappings" : {
 
    "OpenstackRegion2Image" : {
 
      "RegionOne" : {
 
"F17" : "F17-x86_64-cfntools",
 
"U12" : "ubuntu-vm-heat-cfntools"
 
      },
 
      "RegionTwo" : {
 
"F17" : "F17-x86_64-cfntools",
 
"U12" : "ubuntu-vm-heat-cfntools"
 
      }
 
    }
 
  },
 
 
 
  "Resources" : {
 
 
 
    "NetworkEast": {
 
      "Type": "OS::Quantum::Net",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "name": "East Region Network"
 
      }
 
    },
 
 
 
    "SubnetEast": {
 
      "Type": "OS::Quantum::Subnet",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "network_id": { "Ref" : "NetworkEast" },
 
        "ip_version": 4,
 
        "cidr": "10.1.0.0/24",
 
        "allocation_pools": [ {
 
          "start": "10.1.0.10",
 
          "end": "10.1.0.200"
 
          }
 
        ]
 
      }
 
    },
 
 
 
    "RouterEast": {
 
      "Type": "OS::Quantum::Router",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "name": "East Router"
 
      }
 
    },
 
 
 
    "RouterInterfaceEast": {
 
      "Type": "OS::Quantum::RouterInterface",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "router_id": { "Ref" : "RouterEast" },
 
        "subnet_id": { "Ref" : "SubnetEast" }
 
      }
 
    },
 
   
 
    "RouterGatewayEast": {
 
      "Type": "OS::Quantum::RouterGateway",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "router_id": { "Ref" : "RouterEast" },
 
        "network_id": { "Ref" : "ExternalNetworkIdEast" }
 
      }
 
    },
 
  
    "NetworkWest": {
+
* [https://review.openstack.org/#/c/53313/ Patch with proof of concept version]
      "Type": "OS::Quantum::Net",
+
* [http://www.youtube.com/watch?v=kXOVoRWixu8 Live demo]
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "name": "West Region Network"
 
      }
 
    },
 
 
 
    "SubnetWest": {
 
      "Type": "OS::Quantum::Subnet",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "network_id": { "Ref" : "NetworkWest" },
 
        "ip_version": 4,
 
        "cidr": "10.2.0.0/24",
 
        "allocation_pools": [ {
 
          "start": "10.2.0.10",
 
          "end": "10.2.0.200"
 
          }
 
        ]
 
      }
 
    },
 
 
 
    "RouterWest": {
 
      "Type": "OS::Quantum::Router",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "name": "West Router"
 
      }
 
    },
 
 
 
    "RouterInterfaceWest": {
 
      "Type": "OS::Quantum::RouterInterface",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "router_id": { "Ref" : "RouterWest" },
 
        "subnet_id": { "Ref" : "SubnetWest" }
 
      }
 
    },
 
   
 
    "RouterGatewayWest": {
 
      "Type": "OS::Quantum::RouterGateway",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "router_id": { "Ref" : "RouterWest" },
 
        "network_id": { "Ref" : "ExternalNetworkIdWest" }
 
      }
 
    },
 
 
 
    "VPNServiceEast" : {
 
      "Type" : "OS::Quantum::VPNService",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties" : {
 
        "name" : "VPNServiceEast",
 
        "description" : "My new VPN service on East",
 
        "router_id" : { "Ref" : "RouterEast" },
 
        "subnet_id" : { "Ref" : "SubnetEast" }
 
      }
 
    },
 
 
 
  "IKEPolicyEast" : {
 
      "Type" : "OS::Quantum::IKEPolicy",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties" : {
 
        "name" : "IKEPolicyEast",
 
        "description" : "My new IKE policy on East"
 
      }
 
    },
 
 
 
    "IPsecPolicyEast" : {
 
      "Type" : "OS::Quantum::IPsecPolicy",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties" : {
 
        "name" : "IPsecPolicyEast",
 
        "description" : "My new IPsec policy on East"
 
      }
 
    },
 
 
 
    "VPNConnectionEast" : {
 
      "Type" : "OS::Quantum::VPNConnection",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties" : {
 
        "name" : "VPNConnectionEast",
 
        "description" : "My new VPN connection on East",
 
        "peer_address" : { "Ref" : "ExternalGatewayIPAddressEast" },
 
        "peer_id" : { "Ref" : "ExternalGatewayIPAddressEast" },
 
        "peer_cidrs" : [ "10.2.0.0/24" ],
 
        "psk" : "secret",
 
        "ikepolicy_id" : { "Ref" : "IKEPolicyEast" },
 
        "ipsecpolicy_id" : { "Ref" : "IPsecPolicyEast" },
 
        "vpnservice_id" : { "Ref" : "VPNServiceEast" }
 
      }
 
    },
 
 
 
    "VPNServiceWest" : {
 
      "Type" : "OS::Quantum::VPNService",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties" : {
 
        "name" : "VPNServiceWest",
 
        "description" : "My new VPN service on West",
 
        "router_id" : { "Ref" : "RouterWest" },
 
        "subnet_id" : { "Ref" : "SubnetWest" }
 
      }
 
    },
 
 
 
  "IKEPolicyWest" : {
 
      "Type" : "OS::Quantum::IKEPolicy",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties" : {
 
        "name" : "IKEPolicyWest",
 
        "description" : "My new IKE policy on West"
 
      }
 
    },
 
 
 
    "IPsecPolicyWest" : {
 
      "Type" : "OS::Quantum::IPsecPolicy",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties" : {
 
        "name" : "IPsecPolicyWest",
 
        "description" : "My new IPsec policy on West"
 
      }
 
    },
 
 
 
    "VPNConnectionWest" : {
 
      "Type" : "OS::Quantum::VPNConnection",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties" : {
 
        "name" : "VPNConnectionWest",
 
        "description" : "My new VPN connection on West",
 
        "peer_address" : { "Ref" : "ExternalGatewayIPAddressWest" },
 
        "peer_id" : { "Ref" : "ExternalGatewayIPAddressWest" },
 
        "peer_cidrs" : [ "10.1.0.0/24" ],
 
        "psk" : "secret",
 
        "ikepolicy_id" : { "Ref" : "IKEPolicyWest" },
 
        "ipsecpolicy_id" : { "Ref" : "IPsecPolicyWest" },
 
        "vpnservice_id" : { "Ref" : "VPNServiceWest" }
 
      }
 
    },
 
   
 
    "ServerEast" : {
 
      "Type": "AWS::EC2::Instance",
 
      "RegionName" : { "Ref" : "RegionEast" },
 
      "Properties": {
 
        "ImageId"      : { "Fn::FindInMap" : [ "OpenstackRegion2Image",
 
                                              { "Ref" : "RegionEast" },
 
                                              { "Ref" : "LinuxDistribution" } ] },
 
        "InstanceType" : { "Ref" : "InstanceType" },
 
        "KeyName"      : { "Ref" : "KeyName" },
 
        "SubnetId"    : { "Ref" : "SubnetEast" }
 
      }
 
    },
 
   
 
    "ServerWest" : {
 
      "Type": "AWS::EC2::Instance",
 
      "RegionName" : { "Ref" : "RegionWest" },
 
      "Properties": {
 
        "ImageId"      : { "Fn::FindInMap" : [ "OpenstackRegion2Image",
 
                                              { "Ref" : "RegionWest" },
 
                                              { "Ref" : "LinuxDistribution" } ] },
 
        "InstanceType" : { "Ref" : "InstanceType" },
 
        "KeyName"      : { "Ref" : "KeyName" },
 
        "SubnetId"    : { "Ref" : "SubnetWest" }
 
      }
 
    }
 
  },
 
 
 
  "Outputs" : {
 
    "ServerEastIP" : {
 
      "Description" : "East Server IP address",
 
      "Value" : { "Fn::GetAtt" : [ "ServerEast", "PublicIp" ] }
 
    },
 
   
 
    "ServerWestIP" : {
 
      "Description" : "West Server IP address",
 
      "Value" : { "Fn::GetAtt" : [ "ServerWest", "PublicIp" ] }
 
    }
 
  }
 
}
 
</nowiki></pre>
 
  
 
[[File:Ntti3 logo.png|framed|center|NTTI3]]
 
[[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