2015-03-24 23:20 GMT+09:00 Joe Gordon <joe.gord...@gmail.com>: > On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes <jaypi...@gmail.com> wrote: >> On Tue, Mar 24, 2015 at 01:04:46PM +0000, Jeremy Stanley wrote: >> > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: >> > > On Mon, Mar 23, 2015 at 09:35:50PM +0000, Jeremy Stanley wrote: >> > > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote: >> > > > [...] >> > > > > I don't want it suppressed. I want the use of API extensions and >> > > > > the >> > > > > extension framework(s) to be completely dropped for all future >> > > > > API-affecting work. >> > > > [...] >> > > > >> > > > Perhaps controversial, but would it be worthwhile to propose to the >> > > > Defcore working group that future compliance requirements include >> > > > the absence of extensions to officially covered APIs? >> > > >> > > I don't understand what you're getting at, Jeremy. Could you >> > > elaborate? >> > > >> > > What do extensions have to do with future compliance requirements? >> > >> > Defcore's focus is on establishing interoperability standards for >> > OpenStack deployments, to ease the end-user experience. Right now >> > its model depends on a whitelist of API features. As discussed many >> > times before and brought up again in this thread, when providers or >> > distributors "augment" OpenStack APIs to add their own special >> > features without implementing them upstream, this necessarily >> > creates interoperability issues. >> >> Defcore's focus is on determining what "is OpenStack", w.r.t. what is >> brandable as OpenStack. It's focus is not on establishing interoperability >> standards. >> > > I am not sure how you got to that conclusion, yes the defcore process has > been very confusing and I am still not really sure what it was, but some > part of it it *is* about interoperability/ > > Although our wiki does get out of date very easily, I think this still holds > true: > > DefCore sets base requirements by defining 1) capabilities, 2) code and 3) > must-pass tests for all OpenStack products. This definition uses community > resources and involvement to drive interoperability by creating the minimum > standards for products labeled "OpenStack." > > https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
Related to this topic, Nova v2.1 API defines core APIs by itself[1], but I feel now it is better to remove the definition from Nova. On current implementation, the boot of nova-api fails if the above core APIs are not loaded. but that behavior seems conflict to Defcore process, and it would be nice to concentrate on Defcore to define what are core APIs. Thanks Ken Ohmichi --- [1]: https://github.com/openstack/nova/blob/master/nova/api/openstack/__init__.py#L66 __________________________________________________________________________ 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
