Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +0000: > On Sep 28, 2015, at 9:03 AM, Doug Hellmann <d...@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 <s...@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 <d...@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. :-) > > 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! Doug > > At Your Service, > > Mark T. Voelker > > > [1] Do folks know that DefCore is a Board of Directors activity and not a TC > activity? If not, see slides 13-16: > http://www.slideshare.net/markvoelker/defcore-the-interoperability-standard-for-openstack-53040869 > [2] http://www.openstack.org/interop > [3] > http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst?id=ad2b0fd939a4613a68bc154a20c771c002568234#n65 > > > > > Doug > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
