Jeremy Stanley on March 24, 2015 07:28 wrote: On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote: [...] > I'm really not a fan of the Defcore effort. This should come as no > surprise to anyone. I've been quite blunt about my disdain for the > focus on identifying which API things are mandatory and which are > optional, in order to say some vendor's product "is OpenStack". [...]
Understandable--and I'm certainly no fan of bureaucracy and politicking--just pointing out that in the carrots-and-sticks bin we have trademarks as a potential carrot to encourage people running OpenStack commercially to further the goals of our community. If there is broad community support for the idea that standard OpenStack APIs should not be arbitrarily extended downstream because it hurts interoperability, then this might be one way to improve the situation. If there are other means to achieve this then they too should be considered, obviously. [Rockyg] Tl;dr. Propose it to DefCore. They might agree. But they might have action items for developers to make it actionable on DefCore's part. Hey, it sounds like a reasonable request to me, and it's a large operator making the request for DefCore to recognize that extensions break interoperability. Plus, Defcore specifically states that vendor specific code within OpenStack is not considered for inclusion in the Defcore capabilities/test/designated code sets. So then the questions become: * Are there any currently included capabilities that assume extensions work? * Are there any likely candidates for future Defcore sets that assume extensions work? * Will extensions be deprecated before capabilities requiring extensions are in the candidate pool? * Once extensions are deprecated, or it is known that nothing in Defcore sets include the ability to use extensions, are there tests which will validate that extensions are not part of the cloud under test? Something to think about, and if you are serious about limiting the negative effects of extensions, it is certainly worth proposing their elimination and/or restrictions on them to Defcore. And an FYI, APIs and tests are not chosen by DefCore because they are meaningful, but because they are measurable. DefCore uses User Surveys (and who knows what else) to determine adoption rates of OpenStack "capabilities" that are then converted to APIs and tests, etc. If you have a implementable ideas on how better to measure individual clouds/cloud products against the user communities' utilization, they'd love to hear from you. No, really. DefCore wants to hear of better ways to ensure that clouds with the OpenStack trademark mean that user implementations on those clouds are portable across compliant vendors within the scope of what those vendors advertise. --rocky -- Jeremy Stanley __________________________________________________________________________ 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
