On 02/04/2016 06:38 AM, Sean Dague wrote:
What options do we have?
<snip>
2) Have a registry of "common" names.
Upside, we can safely use common names everywhere and not fear collision
down the road.
Downside, yet another contention point.
A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.
The above is my choice. I'd also like to point out that I'm only talking
about the *service* projects here -- i.e. the things that expose a REST API.
I don't care about a naming registry for non-service projects because
they do not expose a public user-facing API that needs to be curated and
protected.
I would further suggest using the openstack/governance repo's
projects.yaml file for this registry. This is already under the TC's
administration and the API WG could be asked to work closely with the TC
to make recommendations on naming for all type:service projects in the
file. We should add a service:$type tag to the projects.yaml file and
that would serve as the registry for REST API services.
We would need to institute this system by first tackling the current
areas of REST API functional overlap:
* Ceilometer and Monasca are both type:service projects that are both
performing telemetry functionality in their REST APIs. The API WG should
work with both communities to come up with a 6-12 month plan for
creating a *single* OpenStack Telemetry REST API that both communities
would be able to implement separately as they see fit.
* All APIs that the OpenStack Compute API currently proxies to other
service endpoints need to have a formal sunsetting plan. This includes:
- servers/{server_id}/os-interface (port interfaces)
- images/
- images/{image_id}/metadata
- os-assisted-volume-snapshots/
- servers/{server_id}/os-bare-metal-nodes/ (BTW, why is this a
sub-resource of /servers again?)
- os-fixed-ips/
- os-floating-ip-dns/
- os-floating-ip-pools/
- os-floating-ips/
- os-floating-ips-bulk/
- os-networks/
- os-security-groups/
- os-security-group-rules/
- os-security-group-default-rules/
- os-tenant-networks/
- os-volumes/
- os-snapshots/
* All those services that have overlapping top-level resources must have
a plan to either:
- align/consolidate the top-level resource if it makes sense
- rename the top-level resource to be more specific if needed, or
- place the top-level resource as a sub-resource on a top-level
resource that is unique in the full OpenStack REST API set of top-level
resources
Best,
-jay
__________________________________________________________________________
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
