Open Stack

Unfortunately I’ll miss the team meeting; I have an all-day offsite here at Cisco (and since I’m chairing a track, I can’t even duck out for a while).

My own preference is for the tag “production ready” to disappear into a deep hole in the ground. It’s impossible to define in a useful way.  

I agree about what you say about our focus. More broadly, we want to provide clarity about OpenStack-level initiatives and the individual cross-project and multi-phase activities upon which they are based. Clarity is mostly about good governance: uniform publically-accessible documentation and consistent decision-making. The most visible output is going to be the OpenStack roadmap, but this won’t have utility or credibility if it isn’t backed up by the detail.

Geoff
  
> On Mar 18, 2015, at 7:02 AM, Shamail <itzshamail at gmail.com> wrote:
> 
> 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
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg