<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 9 December 2015 at 09:31, Doug Wiegley <span dir="ltr"><<a href="mailto:dougwig@parksidesoftware.com" target="_blank">dougwig@parksidesoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Dec 9, 2015, at 7:25 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
><br>
> Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:<br>
>> On 3 December 2015 at 02:21, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
>><br>
>>> Armando M. wrote:<br>
>>>> On 2 December 2015 at 01:16, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a><br>
>>>> <mailto:<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>> wrote:<br>
>>>>>    Armando M. wrote:<br>
>>>>>>> One solution is, like you mentioned, to make some (or all) of<br>
>>> them<br>
>>>>>>> full-fledged project teams. Be aware that this means the TC<br>
>>> would judge<br>
>>>>>>> those new project teams individually and might reject them if we<br>
>>> feel<br>
>>>>>>> the requirements are not met. We might want to clarify what<br>
>>> happens<br>
>>>>>>> then.<br>
>>>>>><br>
>>>>>> That's a good point. Do we have existing examples of this or<br>
>>> would we be<br>
>>>>>> sailing in uncharted waters?<br>
>>>>><br>
>>>>>    It's been pretty common that we rejected/delayed applications for<br>
>>>>>    projects where we felt they needed more alignment. In such cases,<br>
>>> the<br>
>>>>>    immediate result for those projects if they are out of the Neutron<br>
>>>>>    "stadium" is that they would fall from the list of official<br>
>>> projects.<br>
>>>>>    Again, I'm fine with that outcome, but I want to set expectations<br>
>>>>>    clearly :)<br>
>>>><br>
>>>> Understood. It sounds to me that the outcome would be that those<br>
>>>> projects (that may end up being rejected) would show nowhere on [1], but<br>
>>>> would still be hosted and can rely on the support and services of the<br>
>>>> OpenStack community, right?<br>
>>>><br>
>>>> [1] <a href="http://governance.openstack.org/reference/projects/" rel="noreferrer" target="_blank">http://governance.openstack.org/reference/projects/</a><br>
>>><br>
>>> Yes they would still be hosted on OpenStack development infrastructure.<br>
>>> Contributions would no longer count toward ATC status, so people who<br>
>>> only contribute to those projects would no longer be able to vote in the<br>
>>> Technical Committee election. They would not have "official" design<br>
>>> summit space either -- they can still camp in the hallway though :)<br>
>>><br>
>><br>
>> Hi folks,<br>
>><br>
>> For whom of you is interested in the conversation, the topic was brought<br>
>> for discussion at the latest TC meeting [1]. Unfortunately I was unable to<br>
>> join, however I would like to try and respond to some of the comments made<br>
>> to clarify my position on the matter:<br>
>><br>
>>> ttx: the neutron PTL say he can't vouch for anything in the neutron<br>
>> "stadium"<br>
>><br>
>> To be honest that's not entirely my position.<br>
>><br>
>> The problem stems from the fact that, if I am asked what the stadium means,<br>
>> as a PTL I can't give a straight answer; ttx put it relatively well (and I<br>
>> quote him): by adding all those projects under your own project team, you<br>
>> bypass the Technical Committee approval that they behave like OpenStack<br>
>> projects and are produced by the OpenStack community. The Neutron team<br>
>> basically vouches for all of them to be on par. As far as the Technical<br>
>> Committee goes, they are all being produced by the same team we originally<br>
>> blessed (the Neutron project team).<br>
>><br>
>> The reality is: some of these projects are not produced by the same team,<br>
>> they do not behave the same way, and they do not follow the same practices<br>
>> and guidelines. For the stadium to make sense, in my humble opinion, a<br>
><br>
> This is the thing that's key, for me. As Anita points out elsewhere in<br>
> this thread, we want to structure our project teams so that decision<br>
> making and responsibility are placed in the same set of hands. It sounds<br>
> like the Stadium concept has made it easy to let those diverge.<br>
><br>
>> definition of these practices should happen and enforcement should follow,<br>
>> but who's got the time for policing and enforcing eviction, especially on a<br>
>> large scale? So we either reduce the scale (which might not be feasible<br>
>> because in OpenStack we're all about scaling and adding more and more and<br>
>> more), or we address the problem more radically by evolving the<br>
>> relationship from tight aggregation to loose association; this way who<br>
>> needs to vouch for the Neutron relationship is not the Neutron PTL, but the<br>
>> person sponsoring the project that wants to be associated to Neutron. On<br>
>> the other end, the vouching may still be pursued, but for a much more<br>
>> focused set of initiatives that are led by the same team.<br>
>><br>
>>> russellb: I attempted to start breaking down the different types of repos<br>
>> that are part of the stadium (consumer, api, implementation of technology,<br>
>> plugins/drivers).<br>
>><br>
>> The distinction between implementation of technology, plugins/drivers and<br>
>> api is not justified IMO because from a neutron standpoint they all look<br>
>> like the same: they leverage the pluggable extensions to the Neutron core<br>
>> framework. As I attempted to say: we have existing plugins and drivers that<br>
>> implement APIs, and we have plugins that implement technology, so the extra<br>
>> classification seems overspecification.<br>
>><br>
>>> flaper87: I agree a driver should not be independent<br>
>><br>
>> Why, what's your rationale? If we dig deeper, some drivers are small code<br>
>> drops with no or untraceable maintainers. Some are actively developed and<br>
>> can be fairly complex. The spectrum is pretty wide. Either way, I think<br>
>> that preventing them from being independent in principle may hurt the ones<br>
>> that can be pretty elaborated, and the ones that are stale may hurt<br>
>> Neutron's reputation because we're the ones who are supposed to look after<br>
>> them (after all didn't we vouch for them??)<br>
><br>
> From a technical perspective, if there is a stable API for driver<br>
> plugins, having the driver managed outside of the core team shouldn't<br>
> be a problem. If there's no stable API, the driver shouldn't even<br>
> be outside of the core repository yet. I know the split has happened,<br>
> I don't know how stable the plugin APIs are, though.<br>
<br>
</div></div>Agreed, and making that stable interface is a key initiative in mitaka.<br>
<div><div class="h5"><br>
><br>
> From a governance perspective, I agree it is desirable to enable<br>
> (but not require) drivers to live outside of core. But see the previous<br>
> paragraph for caveats.<br>
><br>
>><br>
>>> dhellmann: we have previously said that projects run by different teams<br>
>> talk to each other over rest interfaces as a way of clearly delineating<br>
>> boundaries<br>
>><br>
>> As much as I agree wholeheartedly with this statement (which I made myself<br>
>> during the GBP/Neutron saga), it's unrealistic to convert the interface<br>
>> between Neutron and its extension mechanisms to be purely restful,<br>
>> especially for the price that will have to be paid in the process.<br>
><br>
> Right, I think what we're saying is that you should stop treating<br>
> these things as extensions. There are true technical issues introduced<br>
> by the need to have strong API guarantees to support out-of-tree<br>
> extensions.  As Sean mentioned in his response, the TC and community<br>
> want projects to have stable, fixed, APIs that do not change based<br>
> on deployment choices, so it is easy for users to understand the<br>
> API and so we can enable interoperability between deployments.<br>
> DefCore depends on these fixed APIs because of the way tests from<br>
> the Tempest suite are used in the validation process. Continuing<br>
> to support extensions in Neutron is going to make broad adoption<br>
> of Neutron APIs for DefCore harder.<br>
><br>
>><br>
>>> sdague: I don't think anything should be extending the neutron API that<br>
>> isn't controlled by the neutron core team.<br>
>><br>
>> The core should be about the core, why would what's built on top be<br>
>> controlled by the core? By comparison, it's like saying a SIG on the<br>
>> physical layer of the OSI stack dictates what a SIG on the session layer<br>
>> should do. It stifles innovation and prevents problems from being solved by<br>
>> the right domain experts.<br>
><br>
> It needs to be possible to build on top of neutron without injecting<br>
> yourself into the guts of neutron at runtime. See above.<br>
<br>
</div></div>In point of fact, it *is* possible, and there is an API to do so, but… most choose not to. I won’t say that’s an argument to keep extensions, but it might be worth examing *why* people are choosing that route, because I think it points to a big innovation/velocity killer in “the openstack way”.<br>
<br>
One possible interpretation: we have all these rules that basically amount to: 1) don’t be so small you can’t be a wsgi/db app, which is expensive in the current wild west mode of building them, 2) don’t be so large that we feel you’ve diverged too much from what we want things to look like, and 3) be exactly like a rest service with some driver backends implementing some sort of *aaS.<br>
<br>
That leaves a pretty narrow, and relatively expensive, runway.<br>
<br>
We don’t want extensions for reasons of interop, fine. I think it’s a fairly silly argument to say that rest api’s can be optional, but extensions to an api can’t, because that extra “/foobar/“ is the killer, but whatever. However, maybe we should devote some thinking as to why neutron extensions are being used, and how we could leverage the dev work that doesn’t feel jumping through the above hoops is appropriate/worth it/etc.<br></blockquote><div><br></div><div>I don't think we're saying we don't want extensions; I think the point is: we don't want extension the way they used to be developed. There's always going to be the need to evolve the API (either to change behavior or to add new one), but not in a way that makes it unpredictable over the iterations.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
doug<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Doug<br>
><br>
>><br>
>><br>
>> That's all I managed to process whilst reading the log. I am sure I missed<br>
>> some important comments and I apologize for not replying to them; one thing<br>
>> I didn't miss for sure was all the hugging :)<br>
>><br>
>> Thanks for acknowledging the discussion and the time and consideration<br>
>> given during the TC meeting.<br>
>><br>
>> Cheers,<br>
>> Armando<br>
>><br>
>> [1] <a href="http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-12-08-20.01.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-12-08-20.01.html</a><br>
>><br>
>>><br>
>>> --<br>
>>> Thierry Carrez (ttx)<br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>