Open Stack

On 28/09/15 16:29 -0400, Doug Hellmann wrote:
>Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +0000:
>> On Sep 28, 2015, at 9:03 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>> >
>> > Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
>> >> On 28 September 2015 at 12:10, Sean Dague <sean at dague.net> wrote:
>> >>> 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.
>> >>
>> >> From my memory, thats how we got here.
>> >>
>> >> The Nova tests needed to use an image API. (i.e. list images used to
>> >> check the snapshot Nova, or similar)
>> >>
>> >> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
>> >> it being the only widely deployed option.
>> >
>> > Right, and I want to make sure it's clear that I am differentiating
>> > between "these tests are bad" and "these tests are bad *for DefCore*".
>> > We should definitely continue to test the proxy API, since it's a
>> > feature we have and that our users rely on.
>> >
>> >>
>> >>> And they could be rewritten to use native APIs.
>> >>
>> >> +1
>> >> Once Glance v2 is available.
>> >>
>> >> Adding Glance v2 as advisory seems a good step to help drive more adoption.
>> >
>> > I think we probably don't want to rewrite the existing tests, since
>> > that effectively changes the contract out from under existing folks
>> > complying with DefCore.  If we need new, parallel, tests that do
>> > not use the proxy to make more suitable tests for DefCore to use,
>> > we should create those.
>> >
>> >>
>> >>> 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.
>> >>
>> >> +1
>> >> Thats a good thing to add.
>> >> But I don't think we had another option in this case.
>> >
>> > We did have the option of leaving the feature out and highlighting the
>> > discrepancy to the contributors so tests could be added. That
>> > communication didn't really happen, as far as I can tell.
>> >
>> >>>> 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.
>> >>
>> >> I can't see us removing the proxy APIs in Nova any time soon,
>> >> regardless of DefCore, as it would break too many people.
>> >>
>> >> But personally, I like dropping them from Defcore, to signal that the
>> >> best practice is to use the Glance v2 API directly, rather than the
>> >> Nova proxy.
>> >>
>> >> Maybe the are just marked deprecated, but still required, although
>> >> that sounds a bit crazy.
>> >
>> > Marking them as deprecated, then removing them from DefCore, would let
>> > the Nova team make a technical decision about what to do with them
>> > (maybe they get spun out into a separate service, maybe they're so
>> > popular you just keep them, whatever).
>>
>> So, here’s that Who’s On First thing again.  Just to clarify: Nova does not need Capabilities to be removed from Guidelines in order to make technical decisions about what to do with a feature (though removing a Capability from future Guidelines may make Nova a lot more comfortable with their decision if they *do* decide to deprecate something, which I think is what Doug was pointing out here).
>>
>> The DefCore Committee cannot tell projects what they can and cannot do with their code [1].  All DefCore can to is tell vendors what capabilities they have to expose to end users (if and only if those vendors want their products to be OpenStack Powered(TM) [2]).  It also tells end users what things they can rely on being present (if and only if they choose an OpenStack Powered(TM) product that adheres to a particular Guideline).  It is a Wonderful Thing if stuff doesn’t get dropped from Guidelines very often because nobody wants users to have to worry about not being able to rely on things they previously relied on very often.  It’s therefore also a Wonderful Thing if projects like Nova and the DefCore Committee are talking to each other with an eye on making end-user experience as consistent and stable as possible, and that when things do change, those transitions are handled as smoothly as possible.
>>
>> But at the end of the day, if Nova wants to deprecate something, spin it out, or keep it, Nova doesn’t need DefCore to do anything first in order to make that decision.  DefCore would love a heads-up so the next Guideline (which comes out several months after the OpenStack release in which the changes are made did) can take the decision into account.  In fact in the case of deprecation, as of last week projects are more less required to give DefCore a heads-up if they want the assert:follows-standard-deprecation [3] tag.  A heads-up is even nice if Nova decides they want to keep supporting something since that will help the “future direction” criteria be scored properly.
>>
>> Ultimately, what Nova does with Nova’s code is still Nova’s decision to make.  I think that’s a pretty good thing.
>
>Indeed! I guess I overestimated the expectations for DefCore. I thought
>introducing the capabilities tests implied a broader commitment to keep
>the feature than it sounds like is actually the case. I'm glad we are
>more flexible than I thought. :-)

ditto! Glad to hear this is the case.

>> And FWIW I think it’s a pretty good thing we’re all now openly discussing it, too (after all this whole DefCore thing is still pretty new to most folks) so thanks to all of you for that. =)
>
>Yes, it was pretty difficult to follow some of the earlier DefCore
>discussions while the process and guidelines were being worked out.
>Thanks for clarifying!
>
>

Thank you both for driving this thread. Sorry for having joined so
late!

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150929/afa9af9a/attachment.pgp>