Re: [openstack-dev] [heat] Sergey Kraynev for heat-core
On 06/27/2014 12:08 AM, Steve Baker wrote: I'd like to nominate Sergey Kraynev for heat-core. His reviews are valuable and prolific, and his commits have shown a sound understanding of heat internals. http://stackalytics.com/report/contribution/heat-group/60 +1 ___ 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
Hi Tim, Maybe instead of just a flag like --nested (bool value) to resource-list we can add optional argument like --depth X or --nested-level X (X - integer value) to limit the depth for recursive listing of nested resources? Best, Bartosz On 05/19/2014 09:13 PM, Tim Schnell wrote: Blueprint: https://blueprints.launchpad.net/heat/+spec/explode-nested-resources Spec: https://wiki.openstack.org/wiki/Heat/explode-resource-list Tim On 5/19/14 1:53 PM, Tim Schnell tim.schn...@rackspace.com wrote: On 5/19/14 12:35 PM, Randall Burt randall.b...@rackspace.com wrote: On May 19, 2014, at 11:39 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 19, 2014 at 03:26:22PM +, Tim Schnell wrote: Hi Nilakhya, As Randall mentioned we did discuss this exact issue at the summit. I was planning on putting a blueprint together today to continue the discussion. The Stack Preview call is already doing the necessary recursion to gather the resources so we discussed being able to pass a stack id to the preview endpoint to get all of the resources. However, after thinking about it some more, I agree with Randall that maybe this should be an extra query parameter passed to the resource-list call. I'Ll have the blueprint up later today, unless you have already started on it. Note there is a patch from Anderson/Richard which may help with this: https://review.openstack.org/#/c/85781/ The idea was to enable easier introspection of resources backed by nested stacks in a UI, but it could be equally useful to generate a tree resource view in the CLI client by walking the links. This would obviously be less efficient than recursing inside the engine, but arguably the output would be much more useful if it retains the nesting structure, as opposed to presenting a fully flattened soup of resources with no idea which stack/layer they belong to. Steve Could we simply add stack name/id to this output if the flag is passed? I agree that we currently have the capability to traverse the tree structure of nested stacks, but several folks have requested this capability, mostly for UI/UX purposes. It would be faster if you want the flat structure and we still retain the capability to create your own tree/widget/whatever by following the links. Also, I think its best to include this in the API directly since not all users are integrating using the python-heatclient. +1 for adding the stack name/id to the output to maintain a reference to the initial stack that the resource belongs to. The original stated use-case that I am aware of was to have a flat list of all resources associated with a stack to be displayed in the UI when the user prompts to delete a stack. This would prevent confusion about what and why different resources are being deleted due to the stack delete. This use-case does not require any information about the nested stacks but I can foresee that information being useful in the future. I think a flattened data structure (with a reference to stack id) is still the most efficient solution. The patch landed by Anderson/Richard provides an alternate method to drill down into nested stacks if the hierarchy is important information though this is not the optimal solution in this case. Tim ___ 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
Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core
+1 On 04/23/2014 07:53 AM, Liang Chen wrote: +1 ! On 04/23/2014 02:43 AM, Zane Bitter wrote: Resending with [Heat] in the subject line. My bad. On 22/04/14 14:21, Zane Bitter wrote: I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana design summit. His code reviews are of extremely high quality IMO, and he has been reviewing at a rate consistent with a member of the core team[1]. One thing worth addressing is that Thomas has only recently started expanding the focus of his reviews from HOT-related changes out into the rest of the code base. I don't see this as an obstacle - nobody is familiar with *all* of the code, and we trust core reviewers to know when we are qualified to give +2 and when we should limit ourselves to +1 - and as far as I know nobody else is bothered either. However, if you have strong feelings on this subject nobody will take it personally if you speak up :) Heat Core team members, please vote on this thread. A quick reminder of your options[2]: +1 - five of these are sufficient for acceptance 0 - abstention is always an option -1 - this acts as a veto cheers, Zane. [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [2] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ 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
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
+1 On 02/09/2014 11:38 PM, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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
Re: [openstack-dev] [heat] Nomination for heat-core
Hi all, I would like to thank you for the nomination, yours votes and trust you gave me. I know that with great power comes big responsibility. I will do my best and I will not let you down. Thanks, Bartosz On 12/19/2013 03:21 AM, Steve Baker wrote: I would like to nominate Bartosz Górski to be a heat-core reviewer. His reviews to date have been valuable and his other contributions to the project have shown a sound understanding of how heat works. Here is his review history: https://review.openstack.org/#/q/reviewer:bartosz.gorski%2540ntti3.com+project:openstack/heat,n,z If you are heat-core please reply with your vote. cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration
Hi, On 11/15/13 9:17 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: You are right. At the same time heat feature should not enforce some specific deployment requirements to other openstack components especially taking into account different security considerations. I am trying to rise a concern about possible security implications of that particular approach of using exposed openstack APIs and bring security requirements to the table for discussion. Probably this will help to design better solution for heat to heat or DC to DC communication if it exists. I hope that there is a room for discussion and it is possible to influence on the final design and implementation. I really want this feature to be flexible and useful for most of OpenStack deployments rather then for some specific deployment case.s, Georgy Okrokvertskhov Thank you for your security concerns. There is a room for discussion and possibility to influence the final design. This is the reason why I started this discussion. On 11/15/2013 01:41 PM, Zane Bitter wrote: Good news, everyone! I have created the missing whiteboard diagram that we all needed at the design summit: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram I've documented 5 possibilities. (1) is the current implementation, which we agree we want to get away from. I strongly favour (2) for the reasons listed. I don't think (3) has many friends. (4) seems to be popular despite the obvious availability problem and doubts that it is even feasible. Finally, I can save us all some time by simply stating that I will -2 on sight any attempt to implement (5). Zane thank you for creating this diagram! I think it was really the missing piece. Without it people were confused. Right now I think they have better understanding of the possible solutions. On 11/15/2013 01:41 PM, Zane Bitter wrote: On 11/15/13 2:58 PM, Zane Bitter zbit...@redhat.com wrote: So, to be clear, this is option (4) from the diagram I put together here: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram It's got a couple of major problems: * When a whole region goes down, you can lose access to the Heat instance that was managing still-available resources. This makes it more or less impossible to use Heat to manage a highly-available global application. * Instances have to communicate back to the Heat instance that owns them (e.g. for WaitConditions), and it's not yet clear that this is feasible in general. There are also a number of other things I really don't like about this solution (listed on the wiki page), though reasonable people may disagree. cheers, Zane. Yes. You are right. The proof of concept version I implemented is the option (4). I agree with you about the problems you listed. I am not so concerned about the first one (region goes down) but the second one will be a bigger problem in production and I did not notice it before. Also exposing the API endpoint for all the services maybe not the best solution from the security perspective. We probably should go with option (2). On 11/16/2013 09:20 AM, Zane Bitter wrote: On 15/11/13 22:17, Keith Bray wrote: use Heat in that region to do it, you can Adopt the resources into a Heat stack in that region. I don't see how 2 is Robust against failure of whole region because if the region on the left part of the picture in 2 goes down, you can't manage your global stack or any of the resources in the left region that are part of that global stack. All you could manage is a subset of resources by manipulating the substack in the right region, but you can do this in 4 as well using Adopt. 4 is a simpler starting use case and easier (IMO) for a user of the system to digest, and has the HUGE advantage of being able to orchestrate deploying resources to multiple regions without a service operator having to have Heat setup and installed in EVERY region. This is particular important for a private cloud/heat person trying to deploy to public cloud.. If doing so requires the public cloud operator have Heat running, then you can't deploy there. If no Heat in that region is required, then you can use your own instance of Heat to deploy to any available openstack cloud. That is a HUGE benefit of 4. Good point, I've added that to the Pro/Con in the wiki. It is the benefit but I think for now we can assume that we have Heat service deployed in each region. The implementation differences between option (2) and (4) does not look like to be big. May be we can add new option in heat configuration file to choose the way to create in different region in case when heat service is not available. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best,
Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration
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. Best, Bartosz 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] [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
Re: [openstack-dev] [heat] Proposal for new heat-core member
On 10/25/2013 09:12 PM, Steven Dake wrote: Hi, I would like to propose Randall Burt for Heat Core. He has shown interest in Heat by participating in IRC and providing high quality reviews. The most important aspect in my mind of joining Heat Core is output and quality of reviews. Randall has been involved in Heat reviews for atleast 6 months. He has had 172 reviews over the last 6 months staying in the pack [1] of core heat reviewers. His 90 day stats are also encouraging, with 97 reviews (compared to the top reviewer Steve Hardy with 444 reviews). Finally his 30 day stats also look good, beating out 3 core reviewers [2] on output with good quality reviews. Please have a vote +1/-1 and take into consideration: https://wiki.openstack.org/wiki/Heat/CoreTeam +1 Regards, -steve [1]http://russellbryant.net/openstack-stats/heat-reviewers-180.txt http://russellbryant.net/openstack-stats/heat-reviewers-180.txt [2]http://russellbryant.net/openstack-stats/heat-reviewers-30.txt http://russellbryant.net/openstack-stats/heat-reviewers-30.txt ___ 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
Re: [openstack-dev] [Heat] Multi region support for Heat
First of all sorry for the late reply. I needed some time to understand you vision and check a few things. On 07/24/2013 08:40 AM, Clint Byrum wrote: Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700: Clint, On Jul 23, 2013, at 10:03 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700: On 07/23/2013 10:46 AM, Angus Salkeld wrote: On 22/07/13 16:52 +0200, Bartosz Górski wrote: Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat What immediatley looks odd to me is you have a MultiCloud Heat talking to other Heat's in each region. This seems like unneccessary complexity to me. I would have expected one Heat to do this job. Yes. You are right. I'm seeing it now. One heat talking to other heat service would be an overkill and unnecessary complexity. Better solution is to use one heat which will be talking directly to services (nova, glance, ...). Also solution with two heat services (one for single region and one for multi region) has a lot of common parts. For example single region heat needs to create a dependencies graph where each node is a resource and multi region a graph where each node is template. So in fact it is better to have only one but more powerful heat service. It should be possible to achieve this with a single Heat installation - that would make the architecture much simpler. Agreed that it would be simpler and is definitely possible. However, consider that having a Heat in each region means Heat is more resilient to failure. So focusing on a way to make multiple Heat's collaborate, rather than on a way to make one Heat talk to two regions may be a more productive exercise. I agree with Angus, Steve Baker, and Randall on this one. We should aim for simplicity where practical. Having Heat services interacting with other Heat services seems like a whole category of complexity that's difficult to justify. If it were implemented as Steve Baker described, and the local Heat service were unavailable, the client may still have the option to use a Heat service in another region and still successfully orchestrate. That seems to me like a failure mode that's easier for users to anticipate and plan for. Steve I really like you concept with the context as a resource. What do you think how we should proceed with it to make it happened? What looks wared for me is the concept that orchestration service deployed in one region can orchestrate other regions. My understating of regions was that they are separated and do not know about each other. So the heat service which is responsible for orchestrating multi region should not be deployed in any of those regions but somewhere else. Right now I also do not see a point for having separate heat service in each region. One heat service with multi region support not deployed in any of the existing regions (logically not physically) looks fine for me. I'm all for keeping the solution simple. However, I am not for making it simpler than it needs to be to actually achieve its stated goals. Can you further explain your perspective? What sort of failures would you expect a network of coordinated Heat services to be more effective with? Is there any way this would be more simple or more elegant than other options? I expect partitions across regions to be common. Regions should be expected to operate completely isolated from one another if need be. What is the point of deploying a service to two regions, if one region's failure means you cannot manage the resources in the standing region? Active/Passive means you now have an untested passive heat engine in the passive region. You also have a lot of pointers to update when the active is taken offline or when there is a network partition. Also split brain is basically guaranteed in that scenario. Active/Active(/Active/...), where each region's Heat service collaborates and owns its own respective pieces of the stack, means that on partition, one is simply prevented from telling one region to scale/migrate/ etc. onto another one. It also affords a local Heat the ability to replace resources in a failed region with local resources. The way I see it working is actually pretty simple. One stack would lead to resources in multiple regions. The collaboration I speak of would simply be that if given a stack that requires crossing regions, the other Heat is contacted and the same stack is deployed. Cross-region attribute/ref sharing would need an efficient way to pass data about resources as well. Anyway, I'm not the one doing the work, so I'll step
Re: [openstack-dev] [Heat] Multi region support for Heat
On 07/25/2013 06:38 PM, Zane Bitter wrote: On 25/07/13 17:08, Bartosz Górski wrote: First of all sorry for the late reply. I needed some time to understand you vision and check a few things. On 07/24/2013 08:40 AM, Clint Byrum wrote: Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700: Clint, On Jul 23, 2013, at 10:03 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700: On 07/23/2013 10:46 AM, Angus Salkeld wrote: On 22/07/13 16:52 +0200, Bartosz Górski wrote: Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat What immediatley looks odd to me is you have a MultiCloud Heat talking to other Heat's in each region. This seems like unneccessary complexity to me. I would have expected one Heat to do this job. Yes. You are right. I'm seeing it now. One heat talking to other heat service would be an overkill and unnecessary complexity. Better solution is to use one heat which will be talking directly to services (nova, glance, ...). +1, and this is reasonably easy for Heat to do, simply by asking for a different region's service catalog from keystone. Also solution with two heat services (one for single region and one for multi region) has a lot of common parts. For example single region heat needs to create a dependencies graph where each node is a resource and multi region a graph where each node is template. I'm not convinced about the need for this though. I looked at your example on the wiki, and it just contains a bunch of East resources that reference each other and a bunch of West resources that reference each other and never the twain shall meet. And that seems inevitable - you can't, e.g. connect a Cinder volume in one region to a Nova server in another region. So I'm wondering why we would ever want to mix regions in a single template, with a single dependency graph, when it's not really meaningful to have dependencies between resources in different regions. There's no actual orchestration to do at that level. It seems to me your example would have been better as two templates (or, even better, the same template launched in two different regions, since I couldn't detect any differences between East vs. West). Note that there are plans in the works to make passing multiple files to Heat a more pleasant experience. I think creating an OS::Heat::Stack resource with a Region property solves 95%+ of the problem, without adding or modifying any other resources. We want to start from something simple. At the beginning we are assuming no dependencies between resources from different region. Our first use case (the one on the wikipage) uses this assumptions. So this is why it can be easily split on two separate single region templates. Our goal is to support dependencies between resources from different regions. Our second use case (I will add it with more details to the wikipage soon) is similar to deploying two instances (app server + db server) wordpress in two different regions (app server in the first region and db server in the second). Regions will be connected to each other via VPN connection . In this case configuration of app server depends on db server. We need to know IP address of created DB server to properly configure App server. It forces us to wait with creating app server until db server will be created. More complicated use case with load balancers and more regions are also in ours minds. Thanks, Bartosz cheers, Zane. So in fact it is better to have only one but more powerful heat service. It should be possible to achieve this with a single Heat installation - that would make the architecture much simpler. Agreed that it would be simpler and is definitely possible. However, consider that having a Heat in each region means Heat is more resilient to failure. So focusing on a way to make multiple Heat's collaborate, rather than on a way to make one Heat talk to two regions may be a more productive exercise. I agree with Angus, Steve Baker, and Randall on this one. We should aim for simplicity where practical. Having Heat services interacting with other Heat services seems like a whole category of complexity that's difficult to justify. If it were implemented as Steve Baker described, and the local Heat service were unavailable, the client may still have the option to use a Heat service in another region and still successfully orchestrate. That seems to me like a failure mode that's easier for users to anticipate and plan for. Steve I really like you concept with the context as a resource
[openstack-dev] [Heat] Multi region support for Heat
Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat Thanks, Bartosz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
