ServiceCatalogTNG

Service Catalog TNG
One of the central concepts in OpenStack is the Service Catalog. This is a centralized repository in Keystone which describes all the services available in the cloud. It has grown up organically over time, and now, with substantial use out in the field, it's time to evaluate what changes need to be made to support OpenStack's growth in the future.

Key Proposed Changes

 * Define formal jsonschema for service catalog
 * Including formalizing things that have only been convention (i.e. urls)
 * Define formal registry for Well Known Names.
 * 'compute' should always mean the same thing, regardless of cloud
 * Remove intrinsic ${tenant_id} concept from service catalog
 * Make anonymous catalog possible
 * Provide a new Keystone resource for TNG representation of Service Catalog
 * Existing access methods to SC will not break
 * Library to access service catalog used by servers
 * Reduces requirement of carrying the whole SC around on every RPC message

Open Questions
Q1: do we need the concepts of public, admin, internal urls?

Q2: is project_id actually a first order construct in urls for projects (swift excepted)?

Mitaka Goals

 * Cross project spec landed with statement of principles
 * Removal of project_id from as many projects as possible
 * Resolution of Open Questsions
 * Draft of JSON Schema for new catalog

Weekly Standup
The effort has a weekly 30 minute stand up in #openstack-meeting-cp at 15:00 UTC on Thursdays.