Open Stack

On Thu, Jun 13, 2013 at 6:49 PM, Ken Wronkiewicz
<ken.wronkiewicz at rackspace.com> wrote:

>
> Steven Hardy wrote:
> > 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.


+1 on all of this.

There was a brief conversation on #heat about this, and I'll recap it
here to be more concrete. The idea is that the user should have two
options when deciding to use Heat's Autoscale support:

1. If they're buying into Heat's other orchestration features
(templates or API), they can specify the scaling configuration in
terms of their Heat stack as they've already defined, either in a
template or in the API.

2. If they're not using templates or the other Heat API features, they
can specify lower-level details about how to scale with a simple API.
This would be similar to how Otter does things now, which is by
declaring scaling profiles with what are basically the arguments of
the "nova boot" call to make when it needs to scale.

This way users won't need to be afraid of "orchestration" if they're
just thinking in terms of "I need to boot more instances under these
conditions"; we can just point them at the appropriate API. Or, as you
pointed out Ken, if they're using a different orchestration system and
just want to take advantage of Heat's autoscale.

Please correct me where I'm wrong! :-)

--
IRC: radix
Christopher Armstrong
Rackspace