Open Stack

On Thu, Sep 5, 2013 at 2:54 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com>wrote:

> I'm glad to hear other folks are less concerned by these issues than I am.


I have concerns (and have voiced them) but I'm not sure I have a better
answer than the path we're on.  I'm also not sure it's the right approach.
 I do have concerns that proliferation can result in a watered down version
of OpenStack.  I also think that things will and do suffer in terms of
quality, manageability and the desire that some have for compat across
public clouds.

I know there are arguments that more projects/programs will help compat,
but I disagree.  I think more projects/programs offers more opportunities
for cusomization, but that's a completely different topic. :)

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.
>

It's a very unpopular view it seems but personally I still like the IaaS
model as being a core component.

>
> 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.


Yeah, I agree with you here.  I think I need to go back and study what we
were planning there and what it gets us.

> 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.
>

I was on the other side of the "more" projects debate and I still think
it's a concern.  At the same time I don't pretend to believe that myself or
even the TC in general should be able to make decisions about what the
community works on or doesn't.  One thing that I think would be useful
however is to come up with some more stringent and well defined criteria
for graduation from incubation.  This would include things like diversity
and consistency in contributors.

>
>     - 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
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130905/7f5b877e/attachment-0001.html>