Open Stack

After reading this thread and etherpad and other places I have big concern about tagging.

MY expectation that some small set of tags will be define that will help define "release bundles".

Each of bundle  is targeted toward broad use case and ensure that its component versions work together with certain level of maturity and stability.

But more I read the more I see that tags are just generic tagging facility with poor to none definition of the tag, no consistency how the same tag used

by different people and by different WG.

This will create even more confusion than we have now for releases.

At least now everybody knows what it is even though it does not provide some of the information we and others want about the release.

Is there a defined process how TAGs are defined?

I feel that TAG is very powerful and flexible mechanism but need to be very careful handled to bring clarity and not more confusion.

Creating a couple of dimensions and then tags for different categories within them feel like a good starting point.



Thanks,

Arkady



----- Original Message -----

> From: "Shamail" <itzshamail at gmail.com<mailto:itzshamail at gmail.com>>

> To: "Roland Chan" <roland at aptira.com<mailto:roland at aptira.com>>

>

> 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.



I agree on all three counts, but particularly with regard to the last two, this is why in the mid-cycle we ended up having a fairly lengthy discussion about what "maturity" really means and how to break these high level desirable but open to interpretation traits into smaller but (ideally) more objective criteria and tag based on those. In particular refer to line 102 onwards:



    https://etherpad.openstack.org/p/PHL-ops-tags



I am not saying we were successful in nailing down in the session, just that it seems like a more productive direction than trying to define a single "product-ready", "mature" or "stable" tag as I don't think we will ever get wide agreement on this and more concerningly if we did it would lead to the last problem you mention effectively negating the changes made to get to a "big tent" model.



Thanks,



Steve



> >> 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<mailto: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<mailto: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/05868

> >> 9.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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Product-wg at lists.openstack.org>

> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg

>



--

Steve Gordon, RHCE

Sr. Technical Product Manager,

Red Hat Enterprise Linux OpenStack Platform



_______________________________________________

Product-wg mailing list

Product-wg at lists.openstack.org<mailto:Product-wg at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg