[OpenStack-DefCore] DefCore Meeting on Designated Sections, Thursday 11am PT

Mark Collier mark at openstack.org
Thu Sep 4 11:12:28 UTC 2014


+1


On September 4, 2014 4:05:18 AM Thierry Carrez <thierry at openstack.org> wrote:

> Right, it's one of those areas where our choice of the terms ("users",
> "core") ends up biting us because it's very overloaded.
>
> We "fight for the users", we do "user surveys" and we have a "user
> committee", but we generally fail to acknowledge our two layers of
> "users": operators (deployers of OpenStack) and end users (people
> actually using the REST APIs). And from the upstream perspective, we
> actually have three layers: distributions/packagers of OpenStack are
> also a "user".
>
> I think we did a great job recently of reaching out to operators and
> deployers, but not that great of a job reaching out to end users. Maybe
> it's time to give end users a clear name and place. Continuing calling
> everything downstream a "user" will likely continue to result in us
> ignoring a large part of them.
>
>
> Mark Collier wrote:
> > I think we are in agreement.
> >
> > Would love to work together on all the ways we can make end user
> > feedback more central over time in everything we do as a community,
> > including the end user working group, the evolution of the user survey
> > to incorporate end user specific feedback, defcore, and helping the
> > foundation hire a kick ass community manager singularly focused on this
> > priority.
> >
> > These are just a few examples.
> >
> >
> >
> > On September 3, 2014 12:03:55 PM Monty Taylor <mordred at inaugust.com> wrote:
> >
> >> I'd like to point out that Jim Blair and Infra are MASSIVE end-users,
> >> and have no direct involvement in writing or deploying OpenStack. It's
> >> easy to forget that and think that end users are not represented in
> >> our current make up. We continually provide direct feedback on
> >> elements of the experience which are poor, both to Rackspace and HP
> >> who are our providers, as well as to the developers.
> >>
> >> The end user is pretty darned important, and when you attempt to be
> >> one, it's crystal clear the OpenStack sees it's user base as the
> >> deployers and distros. I would love to see us cowtow less to them and
> >> pay more attention to the users.
> >>
> >> On Sep 3, 2014 11:29 AM, Mark Collier <mark at openstack.org> wrote:
> >> >
> >> > Great point Alan.
> >> >
> >> > I think from an end user / developer perspective (using the term
> >> here to mean those building apps to target “openstack clouds”), there
> >> is a huge need to know what is going to be there consistently when
> >> encountering an openstack powered cloud in the wild, whether public or
> >> private.
> >> >
> >> > So many things happen before that cloud is deployed that the
> >> developer is targeting, like the extremely active upstream development
> >> where rapid innovation is happening, downstream to distributions that
> >> are productizing that code (sometimes a subset of capabilities and
> >> code), down to operators who are taking those distros/products to
> >> stand up and run services based on them (for internal customers in
> >> private, or external in public cloud), all along the way making
> >> decisions about what is suitable for their customers/markets.  This
> >> creates a lot of diversity in the real world deployments, which is a
> >> double edged sword.
> >> >
> >> > The question is how do we ensure that what comes out at the end of
> >> that long supply chain (for lack of a better word) is of the highest
> >> quality, most relevant, and very consistently applied so that this
> >> developer building “cloud apps” can choose any “openstack cloud” they
> >> want (internal or external) and get a great, consistent experience.
> >>  And one that isn’t likely to break the compatibility of their apps as
> >> that service provider updates to new versions of openstack.
> >> >
> >> > This is why there has always been a sense that the technical
> >> community, represented by the TC, are as well positioned as anyone to
> >> weigh in on these decisions about what would ideally happen
> >> downstream.  It’s easy to dismiss this as “just about commercial
> >> questions and trademarks, leave it to the board” but look at it
> >> another way… someone like Rackspace takes the code from trunk and puts
> >> it into production (this is a gross oversimplification I know).  This
> >> is not about making a product per se, it’s about standing up a service
> >> that people will rely on.  How important is it that a public cloud
> >> like that has Keystone capabilities? What about the Code?  To the end
> >> user… end user, again, meaning someone who is really the customer/user
> >> of the cloud service itself, who who likely cares deeply about API
> >> changes that break capability.  What else do they care about, and how
> >> do our decisions around defcore take those things into consideration?
> >> >
> >> > I do think that as the footprint of OpenStack clouds has grown, we
> >> haven’t necessarily kept up in terms of engaging with this “end user
> >> developer” class, and admittedly the TC is focused on the developers
> >> writing openstack not using the clouds based on it per se.  We do have
> >> several efforts underway to put more focus on engaging with that
> >> aspect of the community and getting that voice into the mix.  There is
> >> a new working group spinning up, a dedicated track at the Atlanta and
> >> Paris Summits, developer.openstack.org WIP, new questions on the user
> >> survey, and at the foundation we are likely to hire a dedicated
> >> community manager for this area in the near future. In the meantime,
> >> any developers who have a perspective on this, please speak up!  Big
> >> decisions are looming and I think we do need to have all stakeholders
> >> voicing their opinions leading up to imminent board vote.
> >> >
> >> > Thanks to everyone who keeps pushing on this topic to put us in the
> >> best position to serve our users in 2015 and beyond!
> >> >
> >> >
> >> >
> >> >> On Sep 2, 2014, at 1:17 PM, Alan Clark <aclark at suse.com> wrote:
> >> >>
> >> >> All,
> >> >>
> >> >> There is another aspect to Designated Sections that I feel is
> >> important and I hope not being missed.  At least It's an aspect that
> >> I'm looking for from designated code sections.   Perhaps it simply
> >> didn't surface in the call last week because it is easier to identify
> >> through other projects than those discussed on the call.
> >> >>
> >> >> Back in the 'spider' discussions, one of the tensions identified
> >> was the need to not inhibit developers ability to innovate, while
> >> through the use of the OpenStack mark conveying code maturity,
> >> completeness and long term stability.  People developing applications,
> >> deploying and administrating OpenStack are keen to understand what and
> >> which features they can confidently write to and deploy, aka features
> >> that are mature, complete and will be sustainable for many future
> >> releases. Icehouse had close to 400 new features, Juno will have a
> >> similar amount. In fact I don't see that slowing down in any near
> >> future.  That shows great innovation! Yet even though we have declared
> >> that the integrated projects are ready for release, we know that not
> >> all of the features fit the "mature, complete and long term
> >> supportable" category.  Several of the blueprints even explicitly make
> >> that declaration.
> >> >>
> >> >> We don't want to block those. In fact the exact opposite, we want
> >> more. The beauty of enabling and including innovative features is for
> >> people to try them out and provide feedback and experience to the
> >> community.
> >> >>
> >> >> But let's not miss the opportunity to also tell the ecosystem about
> >> those areas that are mature and dependable. We have a ton of features
> >> that fit that category. We need to identify those. The creation of
> >> capabilities helps but is not complete. This is best resolved through
> >> the creation of designated sections.   And that is why the TC is
> >> critical for the DefCore effort.  As Thierry delineates, asking the TC
> >> and PTLs opinion on  what code is business necessary is not the right
> >> question.
> >> >>
> >> >> In my opinion, asking the PTLs and TC which code features /
> >> segments are mature, complete, sustainable and part of the long term
> >> vision is the right question to ask.
> >> >>
> >> >> Regards,
> >> >>
> >> >> AlanClark
> >> >>
> >> >>
> >> >>>>> On 8/29/2014 at 01:06 AM, Thierry Carrez <thierry at openstack.org>
> >> wrote:
> >> >>>
> >> >>> Rob_Hirschfeld at Dell.com wrote:
> >> >>>>
> >> >>>>   * Review DefCore Process Chart (attached) * time limited.
> >> >>>>
> >> >>>>   * Review Designated Sections Strawman
> >> >>>> from https://etherpad.openstack.org/p/DefCoreLighthouse.5
> >> >>>
> >> >>>
> >> >>> The call yesterday was a bit busy, but I think we actually clarified
> >> >>> something with respect to the "technical community input on
> >> designated
> >> >>> sections" stage.
> >> >>>
> >> >>> There are two types of proposals in the Designated Sections strawman.
> >> >>> Some projects have /some/ designated sections, while some others
> >> don't
> >> >>> have *any* designated section. In the latter case, at the heart of
> >> that
> >> >>> decision is the fact that a lot of companies in the OpenStack
> >> ecosystem
> >> >>> ship products that do not include the project at all, and Defcore
> >> would
> >> >>> still like to allow those companies to use the "Powered by OpenStack"
> >> >>> trademark license program. I totally respect those decisions: it's a
> >> >>> hard call to make and it's the board prerogative and duty to make it.
> >> >>>
> >> >>> But as far as technical feedback is concerned, it's difficult to ask
> >> >>> Swift contributors if they agree that none of the code they wrote is
> >> >>> necessary to call your product "powered by OpenStack". Of course they
> >> >>> won't agree: it's actually not a judgment of technical value, it's
> >> just
> >> >>> a trademark policy choice. By extension, it's difficult to ask the
> >> >>> Technical Committee, the body representing all those contributors, to
> >> >>> agree that part of the code they produce is not necessary or less
> >> >>> important. That body can only give one answer, and will continue
> >> to do so.
> >> >>>
> >> >>> Now, that doesn't mean you can't get any technical input on the
> >> >>> Designated sections strawman, but quite the opposite: it just has
> >> to be
> >> >>> organized differently. There is still a lot of value in technical
> >> input
> >> >>> to precisely define desi
> >> >>
> >> >> gnated sections lines in the case a project has
> >> >>>
> >> >>> /some/ designated sections. For example for Glance, does it make
> >> >>> technically sense to consider the WSGI framework as replaceable or
> >> not.
> >> >>>
> >> >>> So here would be my suggested way forward: for all the projects that
> >> >>> have "some" designated sections (Nova, Glance, Cinder), organize a
> >> >>> specific call/meeting calling all interested members of our technical
> >> >>> community (individual TC members, project PTL, any contributor
> >> >>> interested) to join and give feedback on the proposed split between
> >> >>> designated and non-designated code in their project. That could be a
> >> >>> 30-min-per-project thing in a 90-min time span, or 3 separate
> >> meetings.
> >> >>>
> >> >>> FWIW, personally, I think the proposed split on Nova, Glance and
> >> Cinder
> >> >>> makes technical sense.
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Defcore-committee mailing list
> >> >> Defcore-committee at lists.openstack.org
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> >> >
> >> >
> >
> >
> >
> > _______________________________________________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee





More information about the Defcore-committee mailing list