Open Stack

I'm glad to hear other folks are less concerned by these issues than I am. I do have to say that I didn't hear anyone mention the IaaS+ discussion during the Moniker discussion, and the question of "why are we considering this project" *was* raised. Personally I too prefer to draw the line at "fabric services that I as a user/developer would find useful", but we still haven't had any strong definition around that as a project or committee.

As to the Program proliferation, it just struck me as "Queue" being an exceptionally specific program compared to many of the existing ones and wondered if we'd accomplished anything by changing from Projects to Programs. One of the goals of that was to try and slow the explosive increase in management overhead, right? If no one else cares, I don't either. I was on the side of "more projects isn't an issue" when that debate happened before; I just wanted to raise the issue for discussion because previously folks seemed to care a lot.

    - Gabriel

> -----Original Message-----
> From: Monty Taylor [mailto:mordred at inaugust.com]
> Sent: Thursday, September 05, 2013 9:42 AM
> To: openstack-tc at lists.openstack.org
> Subject: Re: [openstack-tc] Savanna incubation request
> 
> 
> 
> 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.
> 
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc