Open Stack

On 09/27/2015 08:43 AM, Doug Hellmann wrote:
> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +0000:
>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>>>
>>> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +0000:
<snip>
>>
>> Ah.  Thanks for bringing that up, because I think this may be an area where there’s some misconception about what DefCore is set up to do today.  In it’s present form, the Board of Directors has structured DefCore to look much more at trailing indicators of market acceptance rather than future technical direction.  More on that over here. [1] 
> 
> And yet future technical direction does factor in, and I'm trying
> to add a new heuristic to that aspect of consideration of tests:
> Do not add tests that use proxy APIs.
> 
> If there is some compelling reason to add a capability for which
> the only tests use a proxy, that's important feedback for the
> contributor community and tells us we need to improve our test
> coverage. If the reason to use the proxy is that no one is deploying
> the proxied API publicly, that is also useful feedback, but I suspect
> we will, in most cases (glance is the exception), say "Yeah, that's
> not how we mean for you to run the services long-term, so don't
> include that capability."

I think we might also just realize that some of the tests are using the
proxy because... that's how they were originally written. And they could
be rewritten to use native APIs. Realistically I think use of the image
proxy in Tempest is mostly because the nova API (with proxy) was easier
to write to... 3 years ago.

Changing these tests is definitely a thing that's on the table when they
do a funny thing.

I do agree that "testing proxies" should not be part of Defcore, and I
like Doug's idea of making that a new heuristic in test selection.

>>> situation for us to be relying on any proxy APIs like this. Yes,
>>> they are widely deployed, but we want to be using glance for image
>>> features, neutron for networking, etc. Having the nova proxy is
>>> fine, but while we have DefCore using tests to enforce the presence
>>> of the proxy we can't deprecate those APIs.
>>
>>
>> Actually that’s not true: DefCore can totally deprecate things too, and can do so in response to the technical community deprecating things.  See my comments in this review [2].  Maybe I need to write another post about that...
> 
> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
> those APIs in DefCore as a reason to avoid deprecating them in the code
> even if they wanted to consider them as legacy features that should be
> removed. Maybe that's not true, and the Nova team would be happy to
> deprecate the APIs, but I did think that part of the feedback cycle we
> were establishing here was to have an indication from the outside of the
> contributor base about what APIs are considered important enough to keep
> alive for a long period of time.

I'd also agree with this. Defcore is a wider contract that we're trying
to get even more people to write to because that cross section should be
widely deployed. So deprecating something in Defcore is something I
think most teams, Nova included, would be very reluctant to do. It's
just asking for breaking your users.

	-Sean

-- 
Sean Dague
http://dague.net