[openstack-dev] [Heat] Continue discussing multi-region orchestration
mordred at inaugust.com
Fri Nov 15 19:10:00 UTC 2013
On 11/15/2013 12:24 PM, Bartosz Górski wrote:
> Hi Thomas,
> Each of the two engines will be able to create resources in both regions.
> We do not need to add anything in the heat client.
> Right now when you want to create a new stack (using heat client or
> directly API) you need to provide:
> - stack name
> - template
> - parameters (if need)
> - tenant
> - username
> - password
> - region name (optional)
> The last four (tenant, username, password and region_name) we will call
> default context.
> This context is used in Heat to configure all the openstack clients to
> other service.
> Username, password and tenant is used for authentication.
> Region name is use to get appropriate API endpoint from keystone catalog
> for other openstack service (like nova).
> In case with one region you do not need to specify it because there is
> only one endpoint for each service.
> In multi-region case we have more than one and region name is used to
> get correct one.
> Each nested stack have its own set of openstack clients (nova client,
> neutron client, ... etc.) inside the heat engine.
> Right now for all of them the default context is used to configure
> clients which will be used to create resources.
> There is not option to change the default context for now. What I'm
> trying to do it to add possibility to define different
> context inside the template file. New context can be passed to nested
> stack resource to create clients set with different
> endpoints to call. Heat engine will get appropriate endpoints from
> keystone catalog for specified region name.
> So from heat engine point of view there is not big change in the
> workflow. Heat will parse the template, create the
> dependencies graph and start creating resources in the same way as
> usual. When he will need to created nested
> stack with different context he will just use different set of openstack
> clients (ex. will call services in other region).
> So to sum up each of the two heat engine will be able to create
> resources in both regions if different context will
> be specified. If only default context will be used heat will create all
> resource in the same region where it is located.
One more step with the above and you might get to where I want you to
be, which is to be able to register an additional context myself, that
itself might have a specified endpoint, username, tenant and password.
Yup - so that I could run a heat in RAX and use that heat to orchestrate
resources in RAX and HP.
> On 11/15/2013 08:19 AM, Thomas Spatzier wrote:
>> Hi Bartosz,
>> one thing that is still not clear to me:
>> In the discussion at the summit and in your updated architecture on the
>> wiki it talks about two Heat engines, one in each region, and on-top only
>> the dashboard. So what entity will really do the cross region
>> orchestration? In the discussions I heard people talking about the heat
>> client doing it. But wouldn't that duplicate functionality that is inside
>> the engine into the client, i.e. the client would become an orchestrator
>> itself then?
>> Bartosz Górski <bartosz.gorski at ntti3.com> wrote on 14.11.2013 15:58:39:
>>> From: Bartosz Górski <bartosz.gorski at ntti3.com>
>>> To: openstack-dev at lists.openstack.org,
>>> Date: 14.11.2013 16:05
>>> Subject: [openstack-dev] [Heat] Continue discussing multi-region
>>> Hi all,
>>> At summit in Hong Kong we had a design session where we discussed adding
>>> multi-region orchestration support to Heat. During the session we had
>>> really heated discussion and spent most of the time on explaining the
>>> problem. I think it was really good starting point and right now more
>>> people have better understanding for this problem. I appreciate all the
>>> suggestions and concerns I got from you. I would like to continue this
>>> discussion here on the mailing list.
>>> I updated the etherpad after the session. If I forgot about something or
>>> wrote something that is not right feel free a please tell me about it.
>>>  Blueprint:
>>>  Etherpad:
>>>  Patch with POC version: https://review.openstack.org/#/c/53313/
>>> Bartosz Górski
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev