Open Stack

> Well I'd be interested to fully understand the use-cases which require
> autoscaling but don't require any orchestration.  It seems to me that the
> two are closely related, since when you autoscale stuff you have to manage
> orchestration of provisioning, updating dependent resources, co-ordinating
> updates to instances in the group etc etc, which is obviously what Heat is
> all about.
> 
> > Or another way of thinking about it is if autoscaling was a standalone
> > service provided by the heat project, anyone running that service would
> > have to look very carefully at any heat security advisories to check
> > whether it applies to the autoscaling service.
> >
> > But I'm fine with the "let's build it as a standalone service in Heat
> > and then see if it makes sense to split it out" approach.
>
> Well I'm actually proposing lets add functionality to what we've got and
> think about how it could potentially be made consumable as a standalone
> service.  If we get to the point of actually providing a standalone
> service, then we can revisit the separate project discussion, which would
> address the concerns above.
>
> It would be different if there was an Autoscaling service project either in
> Openstack, or being proposed for incubation, ie something Heat could
> actually use to replace our existing implementation, but there isn't -
> hence my build-on-what-we-have opinion.

Honestly, as one of the public-figures-behind-Otter, I have a hard time thinking of autoscaling entirely separate of some notion of orchestration.  Because the "Fire up a Nova server from an image" that Otter supports is still a orchestration, it's just the simplest-possible-thing-that-will-work orchestration.  

I think the closest use case is really the use-case where you are using Autoscale to drive a custom orchestration system not contained within Heat.  That's still orchestration, just orchestration that Heat does not drive.  We should try to preserve some notion of this, because we are not That Other Cloud Platform, we are the Open Cloud Platform and it's OK if the user wants to plug pieces of their own system into the things that OpenStack provides.

Same goes for the separate AutoScale API.  It doesn't matter and the user doesn't care if it's silently creating Heat structures under the covers when you configure AutoScale.  There's a slice of customer architectures (e.g. Netflix) that really want to treat AutoScale as a piece of the infrastructure instead of a platform.

But none of this precludes Heat continuing to contain the AutoScale functionality.

The way I tend to think of this all is that, considering our present direction forward, Heat is kind of like Nova.  It's a giant chunk of functionality.  It's more than templates and it will diverge from where it is now.  Eventually, we may want to break parts of it out, like they are doing now, but for the time being, it makes sense to just continue forward as one project with the idea that we might eventually break it out later on.  I'd talk further about this, but I'd just say the things that Robert Collins already said.