Open Stack

On 09/05/2013 04:57 AM, Thierry Carrez wrote:
> Gabriel Hurley wrote:
>> I think we have two fundamental questions to answer:
>>
>>   1. Is "Amazon has it, so OpenStack should too" sufficient to grant incubation and ultimately integration (provided all technical bars are met)?
> 
> Personally I don't really consider the "does Amazon have it" angle, but
> rather "is it a critical component of an IaaS+ solution". I define
> "IaaS+" as pure infrastructure as a service + slightly more advanced
> services that act as basic building blocks for application builders
> (things like queues or databases).
> 
> Now Amazon has most components of a decent IaaS+ solution, so there is
> definitely some overlap.

I agree with Thierry. I don't consider Amazon at all. I actually, for
the record, don't care about IaaS or IaaS+ or any of those acronyms.

What I think about is myself. As a person who runs a very large
distributed application across two different public clouds, what things
do I want those clouds to have, and what things do I want those clouds
to be compatible on.

As a person who runs a very large distributed application across two
different public clouds, I can tell you that the answer is NEVER "I want
them to be compatible less" or "to have less shared features". In EVERY
case where Rackspace and HP diverge because some narcissistic product
manager thinks too highly of themselves, it causes me pain, and makes
whatever the feature is effectively unusable.

So when I think about what OpenStack should be offering, I think about
that things would make it easier and more robust to run OpenStack's
Infra systems across multiple clouds.

The main arguments I hear on the other side are:

- What about differentiation?
- What about ability to innovate?

To those I answer:

- differentiation:

It's there, even when they are compatible. HP's cloud is faster.
Rackspace's cloud has servers that behave like real servers. To that
end, we run most of the build farm in HP and we run most of our
long-lived things in Rackspace - but we don't have to use divergent code
to do so.

- innovation

OpenStack is ludicrously open. Come innovate here. I do not care, will
not care, should not care about your ability to go innovate in a corner
without participating.

>>   2. If the answer to #1 is "yes" then should we grant each one a program like we're looking at with Marconi (making the proliferation based on Projects that we were trying to avoid happen all over again), or should there be a program for higher-level services that provide AWS parity (not the IaaS stuff) that things like Marconi, Savanna, etc. go under as projects within that program.
> 
> Programs are all about teams. People working together toward a common
> goal (their mission statement). They elect a PTL who is responsible for
> the whole program. I don't really want to artificially group separate
> teams under an "umbrella" just because they may belong in the same
> category of projects. What would be the benefit of doing that ? I can
> certainly see a lot of drawbacks, like creating groups with no unity and
> competing subgroups.
> 
> Why not grant each separate team its own program ?

I think this should be a case-by-case judgement, not a policy. There's a
reason we have an elected body here (us) Sometimes it makes sense to
lump together (I see no reason for tuskar and tripleo to be part of
separate programs, for instance, they both want to work on openstack
deployment) sometimes it does not (savanna, marconi and trove are all
higher-level, but all also quite different)

That said - I could imagine the opposite arguments for both - tuskar and
tripleo have different teams and slightly different approaches, and
savanna could really be using the trove engine and approach on the impl,
so could really be plugins or extra features to trove by another way of
looking at things.

So I'd think we'd have an interesting debate on either and it might
change depending on arguments people make.