Open Stack

On 18/12/13 04:26, 이준원 wrote:
> Hi, stackers,
>
> I know only little about Heat, and I can't wholly follow recent
> discussions around multi-region support in this mailing list.
> Please help me understand the roadmap or plan about hybrid cloud
> and "bursting" in particular.
>
> I'd like to ask the following questions to the developers who have
> the same interests.
>
> 1) Can we use Heat to deploy to the AWS using the same template
>     as in the OpenStack cloud?

Short answer, no. Heat calls only OpenStack APIs.

In principle, you could write a CloudFormation template for AWS, and one 
of the design goals for Heat is that in most cases you should be able to 
use it with Heat on OpenStack also. Of course you miss out on all of the 
nice features that Heat has which are not present in CloudFormation.

> 2) Will Heat support "bursting" when multi-region is supported?
>     (i.e., auto scaling from the private cloud to the public cloud)

Not in an automated way, where a single autoscaling group spans multiple 
clouds. It's not clear to me how that could work, given that 
configurations would likely be different in different clouds.

What it will allow is to manage a tree of templates (i.e. a top-level 
stack and any nested stacks or providers) that spans multiple clouds.

> If these are not prepared in the Icehouse release, is it possible
> in the J-release? Who's interested in these? Will it be able to
> burst into Rackspace cloud or HP cloud using HOT within next year?

I'm not aware of any plans in this area, but I'm certain there are a 
bunch of things we could do to make this smoother. e.g. (half-baked idea 
off the top of my head) some sort of alarm chaining, so if an 
autoscaling group has reached its maximum capacity it redirects its 
alarms to some other place (e.g. an autoscaling group in some other cloud).

> We're also considering the development of the related features
> if possible and want to know how to be involved step by step.

Hybrid cloud bursting is the holy grail of cloud computing, so 
contributions in this area would be extremely welcome :)

One caveat: to the extent that we can support this within the scope of 
Heat's mission, we should definitely do it. However, it's possible there 
might be things that make more sense for some higher-level service to 
do, and if that turned out to be the case then IMO we would want to 
focus more on features to make Heat a great base on which to build that 
service rather than a place to integrate that service itself. We don't 
need to have that discussion yet though; right now it would be great to 
hear whatever ideas you have.

cheers,
Zane.