Open Stack

On Fri, 2012-10-26 at 14:30 +0200, Thierry Carrez wrote:
> Mark McLoughlin wrote:
> > All of the instructions to Heat about how to orchestrate the launching
> > of an app are supplied as part of the "run my Wordpress app" request in
> > the form of a "template" file. If you know AWS CloudFormations, then you
> > know how this works. Heat borrows heavily from it.
> 
> The main issue I see with us entering this space is that there are many
> competing solutions out there. I'm not entirely convinced there is that
> much value in OpenStack picking one and somehow making the others
> second-class...

Care to list the many competing solutions that you're concerned about
making second-class?

> In particular, the argument could be made that ...

Unclear whether you're relaying perceived potential arguments or your
own view?

> the priority should be in providing the basic services that IaaS is
> about (together with the supporting services that are necessary to run
> those), while leaving the client/management/orchestration/deployment
> space to an ecosystem of competing solutions.

Prioritize basic services, agree. We don't want to dilute our focus by
growing our scope at an unsustainable rate.

Allow a ecosystem of competing solutions to form around those, agree. In
many cases that is the right choice.

However, I do see the project growing (slowly, cautiously) in scope over
time and that should be welcomed. What is considered "basic IaaS" will
change. What users considered advanced features when EC2 was first
launched are now considered trivial and features like CloudWatch and
Auto-Scaling are "basic".

I see Heat as being in the vein - with the increasingly sophisticated
features clouds are providing and how people are using those features, a
orchestration API is becoming pretty essential.

Look at some of the templates listed here:

  http://aws.amazon.com/cloudformation/aws-cloudformation-templates/

and then think about how OpenStack is evolving. Even now, a single
multi-instance launch request may involve talking multiple times to
Glance, Nova, Cinder and Quantum and we shouldn't be recommending a
situation where users need to script this client-side or use a third
party service.

Also, I think both Heat will be improved by being in OpenStack (e.g.
improved in-guest signalling back to Heat) and the rest of OpenStack
will be improved by Heat's inclusion (e.g. helping to drive our
understanding of monitoring and auto-scaling use cases).

> > In considering the incubation proposal, I'd like to see us consider e.g.
> > 
> >   * Is the project a sound technical idea?
> >   * Does the architecture make sense?
> >   * Is the service useful to OpenStack operators or users?
> >   * Are the APIs a good addition to OpenStack APIs?
> >   * Is the project following OpenStack development processes?
> >   * Does the project look like it has a healthy future?
> 
> Incubation is about diverting some common resources (QA, CI, Release
> management) to support the incubating project. So we also need to
> address whether the project ultimately looks like a welcome addition to
> the OpenStack set of projects or if it should just live "in the
> ecosystem"... because incubating a project has a cost.

I agree. I hope I'm helping to make the case for it being a welcome
addition :)

Cheers,
Mark.