Open Stack

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