Open Stack

100% agree that who the determining who the "true audience" of OpenStack is lies directly at the heart of this matter. We can't decide what projects best serve our audience without agreeing on who they are.

And I too disagree wholeheartedly with the assertion that OpenStack's audience are operators. Let me give some examples:

  1. Whether it's a Nebula cloud or an NTT cloud or an HP cloud or Rackspace's new OpenStack cloud, end users are directly using the OpenStack CLIs and APIs every day. They're using Horizon to interact with those clouds in many cases.

  2. Stepping away from the companies that are trying to productize OpenStack in its entirety, there are innumerable people trying to productize one component or their add-on service wherein their users end up using a vanilla "Core" OpenStack install all the time.

  3. You know what the first thing I did when I learned about OpenStack was? I downloaded it and installed it on my server in my personal office so I could stop paying Rackspace to host my development VMs. As a User, that was my first thought. I used vanilla OpenStack and the pre-Diablo Horizon and muddled my way through the completely opaque CLIs and incomplete dashboard and I got my VMs running so I could save myself money and get on with my work.

If OpenStack is for operators, then who are they building a cloud for?

    - Gabriel

> -----Original Message-----
> From: Monty Taylor [mailto:mordred at inaugust.com]
> Sent: Thursday, November 08, 2012 8:56 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] The future of Incubation and Core
> 
> Fascinating. I do believe we've gotten directly to the heart of the matter.
> 
> Before we can decide any of the rest of this, we actually are going to have to
> decide this one.
> 
> I disagree with John. I think that the end users are our users, and the
> operators are people who are running OpenStack as one of their product
> offerings. I think that every time an operator makes a choice that makes their
> cloud operate differently from another OpenStack operator from an API or
> behavioral perspective that the potential ecosystem called OpenStack takes
> another step towards failure.
> 
> I'm not trying to empower the employees of rackspace or the employees of
> HP or the employees of AT&T. I'm trying to empower the end users to not be
> locked in to a specific corporate vendor's solution. I'm trying to make the
> CLOUD a free place. I think Rackspace is too, btw -
> http://www.youtube.com/watch?v=JslKQdujlvU
> 
> However, if I'm wrong and John is right, then I think we need to be clear
> about that because it changes a bunch of assumptions. This whole time I've
> been arguing that it's important that we work together because collectively
> we stand at least a chance of making a dent in the juggernaut that is Amazon
> EC2. If our users are operators, then I think we might have a bunch of small
> clouds who all happen to run OpenStack - but I do not think anyone will care,
> because the end users won't be able to tell.
> 
> You're right - Nova is not EC2 - it has the potential to be MUCH MUCH more.
> EC2 is some company's product. It's a big one, but it's just some random
> product. Sigh. Who cares? I don't. Nova, on the other hand, is something that
> Rackspace and NTT and IBM and HP and Cisco and AT&T and anyone else can
> run - and across which customers are then free to move their business from
> one to the other. OpenStack has the potential to actually be a real ecosystem
> for the end users.
> 
> If OpenStack is nothing more than a way to enable Rackspace to build a
> product called Rackspace Cloud, and HP to build a product called HP Cloud -
> then each of those products competes against EC2 individually and also with
> each other. Guess who wins that? If OpenStack is something that an end-
> user cares about, then Rackspace Cloud and HP Cloud are both competing
> collectively against EC2, and the fact that the OpenStack ecosystem includes
> the strengths of both organizations, and the strengths of the other
> organizations who want to play ball as well becomes a really compelling story
> for the end users. Why would you chose EC2, when Amazon is the only
> company who can provide you service. Why would you not chose to use the
> cloud offering that has multiple compatible implementations?
> 
> In any case - before we choose to call the set of projects we care about core
> or collection or pickle, I think we need to decide whether our users are the
> end users or the operators. I fervently hope that we choose the end users,
> because I think if we do then what we're doing is pretty amazing for the
> world.
> 
> On 11/08/2012 05:20 PM, John Dickinson wrote:
> > Deciding what to call it ("core" v "collection" v "pickle" v etc)
> > get's too much into bikeshedding, I think. The important question is
> > what's in whatever it ends up being called.
> >
> > While I agree that it is vital that we focus on the users, OpenStack's
> > users are generally operators, not end-users. The companies who are
> > part of the community are building the products for the end-users.
> > OpenStack projects are not products. To be very explicit, nova is not
> > EC2, swift is not S3, and Cinder is not EBS.
> > Therefore if our users are the people deploying and running the
> > building blocks upon which they can build products, OpenStack's common
> > release should include the fundamental infrastructure components.
> > Let's focus intently on these pieces to provide world-class cloud
> > infrastructure ("do one thing and do it well").
> >
> > But OpenStack as a whole does rely upon a thriving ecosystem.
> > Focusing releases and most of the foundation's resources on promoting
> > and polishing the core infrastructure projects doesn't preclude
> > encouraging an ecosystem. I'd love to see the foundation host and
> > manage an "ecosystem projects" portal, for example. Promoting (ie
> > marketing) the ecosystem falls very much in line with promoting core
> > infrastructure pieces.
> >
> > So, what I'd like to see is core projects as infrastructure components
> > (API+implementation) that are part of the common release.
> > Docs must be included in this release and should be part of core.
> > "Release management" pieces (a superset of the CI tools) are vital to
> > the project, but are not part of the release itself and should
> > therefore not be in core. Other non-IaaS pieces should not be in core
> > but may be promoted as a group by the foundation as the openstack
> > ecosystem.
> >
> > --John
> >
> >
> >
> >
> >
> > On Nov 8, 2012, at 7:47 AM, Anne Gentle <anne at openstack.org> wrote:
> >
> >> Lots of great discussion here - had me awake at night (okay, early
> >> early morning) thinking of what to respond.
> >>
> >> On Wed, Nov 7, 2012 at 1:47 PM, Gabriel Hurley
> >> <Gabriel.Hurley at nebula.com> wrote:
> >>> We need to step back for a minute and question the supposition that
> >>> a "non-core but blessed by OpenStack" category is benefical.
> >>> I don't believe it is.
> >>>
> >>>
> >>>
> >>> There are serious implications to creating a space which is not core
> >>> but is blessed by the foundation/TC. It sends mixed messages to the
> >>> community and has a significant impact on the ecosystem.
> >>> All the concerns the TC has about crushing ecosystem competition
> >>> when debating incubation apply just as much to creating a second
> >>> "non-core" space.
> >>>
> >>>
> >>>
> >>> There should be Core, and then there should be a thriving community
> >>> which is supported equally by the foundation. Nothing in between. We
> >>> can't play favorites there.
> >>>
> >>>
> >>>
> >>> I also think we're placing too much weight on the value of CI
> >>> infrastructure and release management. Projects have been doing that
> >>> for themselves forever and there's lots of free (or nearly
> >>> free) services for Open Source projects readily available.
> >>>
> >>>
> >>>
> >>> Ultimately making another category is just a way to dodge the hard
> >>> issue of what is truly core. Whether core is Iaas or a viable cloud
> >>> at all levels of the stack... that's the real debate here.
> >>>
> >>>
> >>>
> >>> I agree (even at peril to my own project's status) that Horizon
> >>> (currently core), Ceilometer (currently incubated) and Heat
> >>> (incubated largely by a plurality of abstentions) fall above the
> >>> realm of IaaS. However I think that Core would be excruciatingly
> >>> lacking without the inclusion of higher-layer projects for two main
> >>> reasons:
> >>>
> >>>
> >>>
> >>> 1.       Higher-layer projects are the only check on the unity of
> >>> the "core" projects. Projects that span the APIs of Nova, Glance,
> >>> Swift and Quantum are the ones that discover the pain points.
> >>> They're the ones that can work towards OpenStack feeling cohesive.
> >>> Without those OpenStack is just a trademark and a bunch of arbitrary
> >>> code.
> >>>
> >>> 2.       Higher-layer projects (particularly Horizon) improve
> >>> the discoverability, usability and visibility of OpenStack. At this
> >>> point most new users considering OpenStack experience Horizon first.
> >>> When people want to demo OpenStack's functionalities, they use
> >>> Horizon. That's quite telling. Humans are inherently visual
> >>> creatures and the majority of the future users of "cloud" are not
> >>> the type who want arcane CLIs. Folks from Amazon, Rackspace and any
> >>> other cloud provider will tell you that services experience a huge
> >>> increase in usage when they integrate into the dashboard. Losing
> >>> that from Core benefits nobody.
> >>>
> >>
> >> This point on improving the discoverability, usability and visibility
> >> of OpenStack is mostly what I would look for in a project that wants
> >> to be near OpenStack.
> >>
> >> My thinking is that originally when we "invented" incubation it was
> >> to increase usability and much of the sentiment was to increase
> >> adoption. We also wanted to give support to projects who wanted to
> >> fit into our system because we thought we had a pretty good one -
> >> great CI, coordinated releases, integration testing, organized
> >> in-person meetings, and docs (for pete's sake, docs in open
> >> source!)
> >>
> >>>
> >>> As a final argument, let me flip things the other way and suppose
> >>> that Horizon was designated a "supported" project. If that entails
> >>> the arduous Gerrit review process and having to clear major
> >>> decisions with the broader community rather than just letting my
> >>> team keep building great things... that's enough of a disincentive
> >>> that I'd rather not be "supported". I'll go build something
> >>> autonomously, promote it aggressively, make it dead-simple to
> >>> install, and if it's cool people will use it.
> >>> People will use it in spite of a core component if it's better in
> >>> every metric.
> >>>
> >>
> >> There was a lot of this sentiment in "incubation" discussions too
> >> - that the best projects would float to the top because our system
> >> and OpenStack are so great. What happens now is incubation is the
> >> only way to core and core is perceived as the "end game." I don't
> >> think we want to encourage that only core matters.
> >>
> >> I think it's okay to step back at this time and see if "incubation"
> >> really offers the value we wanted in the first place.
> >> Gabriel's points are well-taken by me - that the original intent
> >> (give projects great systems to make OpenStack better to increase
> >> adoption) could also be served by keeping core small and focused.
> >> Enabling as many additional projects without focusing on trademark is
> >> what we want.
> >>
> >>>
> >>> Long story short, I don't see value in creating another category; I
> >>> think we need to fundamentally define Core, let things be in or out,
> >>> and then devote the foundation's resources to supporting the
> >>> *entire* ecosystem, not just a handful of projects.
> >>
> >> The only part I disagree with here is "devote the foundation's
> >> resources" -- this work is the work of companies and their employees,
> >> making projects (including core) better and serving users. The
> >> Foundation serves to keep OpenStack going for a long, long time by
> >> increasing adoption and collaboration among frenemies.
> >> So if by "support" you mean promotion and inclusion at events,
> >> connecting the dots, finding areas of common ground, sure. But it
> >> doesn't mean Foundation employees keep projects on track (other than
> >> Theirry's paycheck coming from the Foundation because he wants to
> >> remain vendor-neutral which is respectable.) It means that we all
> >> have to work together to keep core great and to give all projects a
> >> chance to rise to the top for increasing adoption and aiding users.
> >>
> >> My proposal would be to keep core small and highly resourced for
> >> integration, and make incubation less of a gatekeeping process and
> >> more of an inclusion process. Probably this means I agree most with
> >> 2 which gets rid of incubation, though I don't know if it offers a
> >> crisp-enough definition of Core. Do we need a better definition of
> >> Core to propose 2 to the Board?
> >>
> >> 2. Product core (gabrielhurley) Do not have an intermediary category
> >> which could carry more duties than rights, but have an inclusive
> >> definition of Core that would include necessary/recommended projects.
> >>
> >> Also did we intend to start this on openstack-dev and then go to the
> >> wider OpenStack list for discussion? I don't think this discussion
> >> just concerns devs. Thanks, Anne
> >>
> >>>
> >>>
> >>> -          Gabriel
> >>>
> >>>
> >>>
> >>> From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com] Sent:
> >>> Wednesday, November 07, 2012 10:45 AM To: OpenStack Development
> >>> Mailing List
> >>>
> >>>
> >>> Subject: Re: [openstack-dev] The future of Incubation and Core
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Nov 7, 2012 at 12:13 PM, Russell Bryant <rbryant at redhat.com>
> >>> wrote:
> >>>
> >>> On 11/07/2012 12:04 PM, Doug Hellmann wrote:
> >>>>
> >>>>
> >>>> On Wed, Nov 7, 2012 at 11:40 AM, Thierry Carrez
> >>>> <thierry at openstack.org
> >>>
> >>>> <mailto:thierry at openstack.org>> wrote:
> >>>>
> >>>> Hi everyone,
> >>>>
> >>>> Incubation is currently an OpenStack project status that grants a
> >>>> promising project more access to OpenStack shared resources,
> >>>> especially in the CI, release management and QA space. That status
> >>>> lets the promising project prove that it is ready to join other
> >>>> official OpenStack core projects for the next full development
> >>>> cycle.
> >>>>
> >>>> In the past governance the Project Policy Board was the only
> >>>> decider on Incubation and Core inclusion. With the new governance,
> >>>> the Technical Committee is still the only decider on Incubation
> >>>> status and still proposes projects for Core inclusion, but the
> >>>> Board of Directors has the possibility to veto that Core inclusion.
> >>>>
> >>>> This creates an awkward process where a project could go all the
> >>>> way through Incubation and be denied Core inclusion at the end of
> >>>> that process, basically wasting OpenStack resources. We need to
> >>>> evolve the Incubation process so that the question of whether a
> >>>> project belongs in "Core" is fully resolved as early as possible.
> >>>> And define how a project can enter, grow or exit the incubation
> >>>> process.
> >>>>
> >>>> This also raises the question of whether "Core" should really be
> >>>> the only destination of an Incubated project. Which triggers the
> >>>> very question of what OpenStack Core actually is. For some it's the
> >>>> collection of OpenStack projects that work well and complement each
> >>>> other, for others Core should only include the IaaS pieces, for
> >>>> others they should represent the bare minimum you need to
> implement
> >>>> to be able to be called an "OpenStack Cloud"...
> >>>>
> >>>>
> >>>> It would be healthy to allow the scope of projects managed by the
> >>>> foundation to evolve over time to be broader than IaaS components.
> >>>> If we need to define "OpenStack Cloud" for brand management, we
> >>>> should be thinking about it at the different levels of the stack.
> >>>> There could be a separate set of "core"
> >>>> projects for IaaS and PaaS, for example.
> >>>
> >>> I agree that I'd like to see the project overall be inclusive
> >>> instead of exclusive.
> >>>
> >>>
> >>>> Once "Core" is defined we can evaluate the need for a category that
> >>>> would still be in "OpenStack" but not have the "Core"
> >>>> label on it. Incubation could then lead two ways.
> >>>>
> >>>>
> >>>> It seems like we want a "supported" category for projects the TC
> >>>> feels are worth spending foundation resources on but the BoD does
> >>>> not want to include in "core" and require that deployers use them
> >>>> to be able to claim they are an "OpenStack Cloud" as you mention
> >>>> above. So projects would start out in the community, move to
> >>>> "incubated" and then to "supported" after the incubation period is
> >>>> up. They could apply separately for "core" status, after being
> >>>> declared "supported" by the TC.
> >>>
> >>> This seems to be the crux of the issue.  If the OpenStack mark is
> >>> going to be wrapped up in what "core" is, then I think it seems fine
> >>> to keep it very limited, and perhaps to minimal IaaS components, but
> >>> *only* if we have a place for everything else that is a positive
> >>> addition to go. A new category like "supported" seems like a great
> >>> idea to me.
> >>>
> >>> My gut feeling of where the line would be is that Heat, Ceilometer,
> >>> and Horizon would all be in this new category, while everything else
> >>> would remain the core.
> >>>
> >>>
> >>>
> >>> That makes sense to me.
> >>>
> >>>
> >>>
> >>> Doug
> >>>
> >>>
> >>>
> >>>
> >>> -- Russell Bryant
> >>>
> >>>
> >>> _______________________________________________
> OpenStack-dev
> >>> mailing list OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> _______________________________________________
> >>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>>
> _______________________________________________
> >> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________ OpenStack-
> dev mailing
> > list OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev