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. WOOT > 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? >> >> Regards, >> Thomas >> >> Bartosz Górski <bartosz.gor...@ntti3.com> wrote on 14.11.2013 15:58:39: >>> From: Bartosz Górski <bartosz.gor...@ntti3.com> >>> To: openstack-dev@lists.openstack.org, >>> Date: 14.11.2013 16:05 >>> Subject: [openstack-dev] [Heat] Continue discussing multi-region >> orchestration >>> 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. >>> >>> References: >>> [1] Blueprint: >>> >> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat >> >> >>> [2] Etherpad: >>> https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud >>> [3] Patch with POC version: https://review.openstack.org/#/c/53313/ >>> >>> >>> Best, >>> Bartosz Górski >>> NTTi3 >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev