> On Sep 29, 2015, at 1:07 AM, Flavio Percoco <fla...@redhat.com> wrote: > > 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 <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. :-) > > ditto! Glad to hear this is the case.
Having two active guidelines at any given time make it easy to update without necessarily breaking the world for everyone. We’re moving a little bit faster now because we are trying to get this right for the community, and course correcting as we see issues arise. > >>> 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 > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
