Open Stack

Hi everyone,

Thanks for sharing this Rocky.  Maybe we can discuss this briefly on our team meeting later today?

Here are some of my thoughts/opinion:
- Agree that defining "production ready" is tough but (if it has to be defined at all by the community), at a minimum, it should be some function of run-time hours and number of critical bugs or other quantitative criteria. Qualitative data such as composition or relevance of the project/service is better left for consideration by the organization that plans to use the service.
- The example given about the various distributions and business models below is a good one.  I think it further illustrates why we shouldn't try to define what is OpenStack as a product beyond the requirements set by DefCore guidelines.  I think our focus, as product team, should be on documenting the long-term priorities for each project, helping with themes, and ensuring that we can find/share commonalities that have the broadest impact (e.g. cross project use-cases and concerns).  
- "production ready" could also mean different things for different verticals and intended use-cases.
- I also have some concerns in general about this tag (unintentionally) becoming the new core/integrated where people start considering everything without this tag as not being ready for prime-time and/or projects that don't necessarily belong together being treated as a set of projects that must be deployed to run production OpenStack clouds.

Thanks,
Shamail 






>> They all draw
>> from the codebase that the OpenStack developers create, and, of course,
>> give their feedback as to what changes are needed to make their
>> particular customers happy. If they're smart, they'll supply developer
>> cycles to help make them happen.
This.  


> On Mar 17, 2015, at 8:24 AM, Roland Chan <roland at aptira.com> wrote:
> 
> There's a fair bit of merit in the argument that the concept of production
> ready is very hard to define and harder to enforce, especially as the code
> base grows larger.
> 
> Do we have a team view on this?
> 
> Roland @ Aptira from mobile.
> Ph: +61 4 28 28 48 58
> 
> On 17/03/2015 12:27 PM, "Rochelle Grober" <rochelle.grober at huawei.com>
> wrote:
> 
>> Folks, I just wanted to highlight this message from the project governance
>> thread.
>> (link to full thread here:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-March/058689.html
>> 
>> I think we need to review this thread and perhaps develop a team response?
>> 
>> Or, maybe some of you want to comment on it?
>> 
>> --Rocky
>> 
>> -----Original Message-----
>> From: Ed Leafe [mailto:ed at leafe.com]
>> Sent: Wednesday, March 11, 2015 15:59
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] Avoiding regression in project governance
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>>> On 03/11/2015 02:40 PM, Jeremy Stanley wrote:
>>>>> I think we can make this work. Assuming more than N (to my mind >
>>>>> 5 or so) deployments report they are using project X, we can say
>>>>> that this is used in production/POC/... and the number of
>>>>> nodes/hypervisors/etc.
>>>>> 
>>>>> This makes it concrete and anonymous to avoid the fishing queries.
>>>>> It also allows our community to enter what they are doing in one
>>>>> place rather than answering multiple surveys. I am keen to avoid
>>>>> generic queries such as "How many hypervisors are installed for
>>>>> public clouds using Xen" but if we have an agreement that >5
>>>>> avoids company identification, I feel this is feasible.
>>> [...]
>>> 
>>> I'm mildly concerned that this adds a strong incentive to start
>>> gaming responses to/participation in the user survey going forward,
>>> once it gets around that you just need N people to take the survey
>>> and claim to be using this project in production so that it can get
>>> the coveted "production-ready" tag. I'm probably a little paranoid
>>> and certainly would prefer to assume good faith on the part of
>>> everyone in our community, but as the community continues to grow
>>> that faith gets spread thinner and thinner.
>> 
>> Allow me to re-propose the idea that we are dealing with two separate
>> entities here, and need two separate entities to make these calls.
>> 
>> There is the the development side of things, where people work hard to
>> get their ideas for OpenStack incorporated into the codebase. There is
>> also the distribution side, where people work hard to get a single
>> deployable package that others can take and make clouds with.
>> 
>> So what is "production-ready"? And how would you trust any such
>> designation? I think that it should be the responsibility of groups
>> outside of OpenStack development to make that call. What would that look
>> like? Well, let me give you an example.
>> 
>> I have Company A that wants to be known as the simplest OpenStack
>> distribution. I invest time and money in packaging the co-gated core
>> along with a few helpful other projects, and make that available to my
>> customers. There is also Company B, who wants to create the most
>> powerful, flexible packaging of OpenStack, and takes the time to not
>> only include the basics, but develops tools to handle the more complex
>> situations, such as cells or HA designs. This package is not for the
>> faint of heart, and for most businesses it would require contracting for
>> the services of Company B in order to get their installation up and
>> running, as well as fine-tuning it and upgrading it. There are also
>> Company C and Company D who target other end-user needs. They all draw
>> from the codebase that the OpenStack developers create, and, of course,
>> give their feedback as to what changes are needed to make their
>> particular customers happy. If they're smart, they'll supply developer
>> cycles to help make them happen.
>> 
>> The longer we try to be both sides of this process, the longer we will
>> continue to have these back-and-forths about stability vs. innovation.
>> 
>> 
>> - -- Ed Leafe
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.14 (GNU/Linux)
>> 
>> iQIcBAEBAgAGBQJVAMjCAAoJEKMgtcocwZqLkKIP/0ReARgypM+eXnu7xDguJIF/
>> 6QW8RI7tdHpBFrRZfrBaRahDstFdPQiaBxj1XhFbzoKP+BrUvvfLMnxhJ5cRX0ey
>> mz842khScuGmLFzteKvLWwyOia425CZQRnNNaHYjiwii3Agu3a5JTnUi0FeDxZi4
>> bD/ZFb/1OxqyVVf2eOJ/T0akVQBqB9QGGNtBnPJEmgEjUl6AhOplLnOkOl1ozRSW
>> svlCE7Wyq/Gtl86Ksbj1rfDdArO9Hlh3lwJxaJikfV3O316kqfjx+v7JVcrwdXrK
>> qqNtDUpC/tjlReDuDmrPixa0e8/z9Go4TiF1F6nQ4LbY8itMzRKeVbrUPrx4ojlh
>> DOE/uOhxh8iTYKOncPsxQlfhbIk0VwzCDWZzDbRxEUpV8Jnzz1ImeosCO3D5/sRL
>> G+Rd2gr9rsbwQxtJLA1Q2zQUqnJ6Vvsvx2BgV87ukl0kudF9X/1NaGrJRmeiKYxk
>> UDgd0ESYnp9GQMCORcoDa6hNKnPA0yLebqOEyi5dGMwem8JHjYFDx6D9fVfkrxlQ
>> 7Kt+SfRmm+1zsHcbZIUz6KEPAvU0cmFdbuG7DwnmKSxpPamUnn3wmpIZRDpdwGIj
>> fY3F2dTeEYoNnTyiitLTCKZYE0KaKpFDOAN+FpDNnQJIqQMn/ksxy9/NHYvsmutD
>> 5DE1LjWhip9IdcVVm+bT
>> =8L0C
>> -----END PGP SIGNATURE-----
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> Product-wg mailing list
>> Product-wg at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg