openstack-poc team mailing list archive

[John Dickinson <me@xxxxxx>]

This is the second message on this thread that has said something to the effect of "there is great benefit to not having 'core' or 'official' or 'approved' parts of the ecosystem" (vs the "core" openstack projects). Yet in both of those messages, option "c" was chosen. How does that work? How is that not option "b"?

--John


On May 5, 2012, at 5:00 PM, Joe Heck wrote:

> Back the original - I like the idea of Vish's option "C" - but that's assuming a lot around what we mean about being "core".
> 
> We're complicating this discussion every time someone uses the word "official", either trying to inject a new "middle state" of something that's not core, but that has some, currently horrifically unclear additional status with us as a community. 
> 
> Here's a strawman (that I'm sure will get some comments) to try and nail down some definitions and differences for some of these terms:
> 
> "CORE"
> =======
> 
> For the sake of argument, this is what I think it means to be "core" based on what I've seen to date:
> 
> CODE/SOURCE:
> *) something that has code associated with it - in one or more repositories that we (openstack) manage
> *) it's embedded and takes advantage of our git repoistories, gerrit code review, and has the use of our resources for doing automated testing, both for gating and post-commit for informational/tracking purposes
> *) has tarballs produces from each repository in a consistent fashion for downstream providers/packagers
> 
> PROJECT MANAGEMENT:
> *) has a specific project on Launchpad with at least two groups managing it:
> - projectname-core, and projectname-drivers
> - manages its bugs in Launchpad based on the project
> - manages its future work in Launchpad using blueprints, series, and milestones that are managed defined by our release manager
> *) follows at least the release cycle that our release manager defines
> *) has a lead that is elected during the openstack election process from it's contributors
> 
> COMMUNITY/LEADERSHIP:
> *) has a lead that is responsible to interact on the PPB for technical and community decisions
> 
> By being core, there's also a guarantee of compatibility between projects, which we enforce (lightly) through our gated development/contrbution process today, getting stronger as tempest comes online.
> 
> The value I see to another project wanting to be core is guaranteed, and gating/blocking, compatibility with the rest of the OpenStack components and their APIs, verified through our CI system. 
> 
> Philosophically, I think we want to keep the core to an absolute minimum. I personally look forward and see pieces fragmenting off Nova to break up the project into more managable pieces being what ends up becoming potential future "core" pieces.
> 
> "OFFICIAL"
> ==========
> 
> Four "things" that are clearly a "part" of OpenStack, but aren't "core":
> 
> - CI, being run/lead by Monty
> - Devstack, and I've no idea who's coordinating that
> - Docs, being run/lead by Anne
> - Web/Community, being run/lead by Stefano (i.e. the public website of openstack)
> - QA/Tempest, being run/lead by Jay and/or Darryl (I'm honestly not sure)
> 
> What do we call these things? To me, these are the "official" projects. We've been vague about how we treat them and where they fit, but it's clear they're critical to all of us.
> 
> These are an intrinsic part of the community and essential and/or responsible for producing the "product" that is OpenStack. The difference between "official" and "core" here being that:
> 1) we apply community resources to making them exist
> 2) they're important to us to deliver the product that is the OpenStack kernel to downstream projects/packagers.
> 3) they don't have elected leaders
> 4) they don't *have to* follow the openstack release process, and don't have deliverables that are generated and made external by our Release manager
> 
> Using this definition, I don't think it's useful or appropriate to call a 3rd party API, or quantum plugin (or keystone plugin, or volume driver, etc) as "official". 
> 
> "COMMUNITY"
> ============
> 
> Everything else - additional APIs that map to the OpenStack kernel, proprietary plugins that provide services or functionality to core pieces (like Keystone and Quantum plugins, Volume drivers) actually have FAR more benefit by NOT being core.
> 
> Key differences:
> * We should provide a means to make these pieces/projects/etc discoverable, and very easily. (and I think we all agree, and Monty is doing some "forge" thing website to make this happen as I understand)
> * The release cycle of these components is completely independent of releases of OpenStack
> * Compatibility is the responsibility of the community project, and we don't gate changes to future work in OpenStack based on it potentially breaking a community project
> * These projects don't need to be open source
> * These projects don't need to be controlled or mandated by OpenStack as an organization or community
> * These projects are where most of the value-add for using OpenStack will be most clear.
> * OpenStack "CORE" is the kernel being made to support *THIS* set of projects - in the kernel/userland metaphor, this is userland. This is where a thousand flowers bloom.
> 
> As we grow OpenStack into the F, G, and H releases, I think we (PTLs especially) should be aiming our projects towards mechanisms and means of supporting the community projects, perhaps even going to the extent of having a straw-man community project that integrates with all the components to make sure we can do this well.
> 
> To my mind, this is where the implementation of 3rd party APIs like OCCI and CDMI fit best. It's also where I see things like the Nexenta volume drivers, an RSA authentication plugin for Keystone, a Cisco plugin for Quantum, and/or Justin's Anything-As-A-Service project.
> 
> This community is where many of the really interesting value-add things happen, and where the mix of additional open-source projects and proprietary projects will really show off the additional value of OpenStack as a platform. Monty has something rolling for a "forge" community environment as a part of the ongoing CI work.
> 
> - joe
> 
> On May 4, 2012, at 2:59 AM, Thierry Carrez wrote:
>> Jay Pipes wrote:
>>>> Openstack-common, openstack-ci, or things we gate the core product on
>>>> (devstack, tempest) should never be part of OpenStack Core (or ever be
>>>> incubated to become core). However they are necessary for us to produce
>>>> OpenStack core, and require our collective attention and support. So
>>>> they need to be blessed in some kind of "official" category meaning they
>>>> are an central part of "OpenStack" as a development community. Maybe
>>>> "OpenStack Companion project"...
>>> 
>>> I don't necessarily view openstack-ci and openstack-common in the same
>>> vein. I think openstack-common actually should be part of core since it
>>> is an important dependency for so many of the core projects (and
>>> becoming more so...). Openstack-ci, tempest and devstack are also
>>> critical pieces, but they are support projects, not necessarily
>>> dependencies. So I would categorize them as "OpenStack Supporting
>>> Projects" or similar.
>> 
>> Agreed, but openstack-common probably needs to become a formal library
>> before it can be part of "Core"... As long as it's an area to stage
>> common stuff waiting to be copied into real projects, it's more a
>> "supporting project".
>> 
>>>> Another category could be necessary to describe external
>>>> projects/plug-ins that are continuously tested with OpenStack Core as
>>>> part of our integration testing and for which we therefore have a pretty
>>>> good idea of how well they work with OpenStack. Choosing the right term
>>>> is a bit more tricky here since most names are a bit overloaded. Maybe
>>>> "OpenStack recommended project/plugin"...
>>> 
>>> The term "recommended" comes with a lot of baggage :) I don't want
>>> plugins to be recommended or suggested -- at least by the community;
>>> companies should feel free to recommend or suggest whatever they feel is
>>> best for their distro or deployment. I just want a category called
>>> "OpenStack Extensions" (or Plugins, depending on what the
>>> semantics-du-jour happen to be.
>> 
>> It's certainly better :) So test-integrated projects/plugins would be
>> called "OpenStack extensions" while stuff supposed to be compatible with
>> openstack (but not tested by us) would be called...
>> OpenStack-supposedly-compatible ecosystem add-ons ?
>> 
>> -- 
>> Thierry Carrez (ttx)
>> Release Manager, OpenStack
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack-poc
>> Post to     : openstack-poc@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack-poc
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack-poc
> Post to     : openstack-poc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature