Open Stack

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