Open Stack

Thanks for the feedback Geoff.

Sorry that you can't join us today, but good luck with the track at the offsite!



> On Mar 18, 2015, at 10:28 AM, Geoff Arnold <geoff at geoffarnold.com> wrote:
> 
> 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
>