Open Stack

On 04/09/14 17:16, Tim Bell wrote:
> The End User working group is being described at https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is establishing the structure.

See also: the user committee mailing list
http://lists.openstack.org/pipermail/user-committee/2014-August/thread.html
- for a robust discussion about kicking the working group off.


> Tim
> 
>> -----Original Message-----
>> From: Thierry Carrez [mailto:thierry at openstack.org]
>> Sent: 04 September 2014 11:05
>> To: defcore-committee at lists.openstack.org
>> Subject: Re: [OpenStack-DefCore] DefCore Meeting on Designated Sections,
>> Thursday 11am PT
>>
>> 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-commit
>>>>>> tee
>>>>>
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>