The service catalog offers cloud consumers an initial view to all the available services in an OpenStack cloud along with additional information about regions, API versions, and projects available. This catalog is to help make it easy to efficiently find information about the services, such as how to configure communications between services. But the catalog is also terribly underused, under documented, and inconsistently configured among most services. By standardizing the service catalog we can provide a better user experience with OpenStack.
The service catalog might be the first interaction a user has with an OpenStack cloud to understand what the cloud offers in services and resources. That interaction can be confusing, inconsistent between cloud providers, and contain names and numbers that are mysterious and need decoding.
Providers making a service catalog might not think about consumers who see multiple service catalogs in a single week.
The API Working Group did some initial fact finding about the varieties of service catalogs available, and discovered just how varied the catalog can be. See https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog.
As an example of the inconsistency, cloud providers have filled in the “name” object as all three: “nova”, “cloudServersOpenStack” and “Compute”.
Such a diverse service catalog means that services don’t depend on it being consistent, SDK devs don’t completely understand it, and it requires applications to encode cloud-specific behavior.
Here are some concrete examples of information that must be encoded because it cannot be determined from the service catalog.
For example, a nova.conf file has to indicate exact URLs for many API endpoints:
[glance] api_servers = http://127.0.0.1:9292 [neutron] url = http://127.0.0.1:9696
Ideally, rather than hardcoding these URL/port values in configuration files, the service catalog could provide discoverability for those.
Another example, the catalog_info = volume:cinder:publicURL in nova.conf is a configuration setting to set the info to match when looking for cinder in the service catalog. Format is separated values of the form:
There’s also an endpoint_template nova.conf variable that overrides the service catalog lookup with template for cinder endpoint, such as http://localhost:8776/v1/%(project_id)s.
While we are working through many of these issues, we are ensuring that projects understand that user experience includes consistency, discoverability, and simplicity as design tenets for service catalog incremental improvements.
The following is a vision of where we want to get to with the service catalog in OpenStack.
What we want to solve for:
Standard required naming for endpoints (versioned vs. unversioned, contains project ID vs. no project ID).
- We want unversioned endpoints so that the user can get information about multiple available versions in a given cloud.
- We do not want project ID, account ID, or tenant ID as part of the resource URI for an OpenStack API endpoint.
- Standard naming means all consumers, including other OpenStack services, can trust what the value of type=’volume’ will be.
List of changes needed in existing clouds/products to comply with this.
- We want DevStack to follow these standards as the best practice example.
- We want to use JSON Schema to define the API for the service catalog to ensure understanding and compliance.
- JSON Schema must allow for “extra” data so that we can continue with name, and vendor-specific “Extra” things during the transition(s).
- Known types such as service_type can be documented in projects.yaml in the openstack/governance git repository.
List of changes in OpenStack projects that would rely on this standard, thus making sure we’ve got it right.
Published guidelines we recommend that DefCore requires of cloud provider’s service catalogs going forward. These guidelines can be created in the API Working Group set of guidelines.
Documentation for all new projects to comply with the service catalog standards defined by the guidelines.
Top difficulties with the service catalog for SDK devs are currently:
Documentation can improve some of the difficulties. Standards and guidelines should be published from within the Cloud Admin Guide, the Installation Guides, and the Identity service (keystone) developer documentation.
The list of changes is gathered here:
What happens currently is DevStack’s configuration becomes a de facto standard for endpoint URL naming, which then indicates both the name and type standard.
Anne Gentle annegentle Augustina Ragwitz Sean Dague sdague Dolph Matthews dolphm
Create a guideline in the API Working Group repository for service types, names, endpoint URLs, and configuration for cloud providers creating service catalog entries.
Create a JSON Schema for the service catalog, to be stored as a tempest test, so that the refstack repo can make use of it. Tempest tests can check for valid entries. So the Identity project won’t enforce the list, rather a test in Tempest can enforce for interoperability. The test will check each entry based on JSON Schema, such as:
DevStack should be the reference implementation for best practices in service catalog entries.
Create a conceptual topic about the service catalog using http://dolphm.com/openstack-keystone-service-catalog/ as a starting point.
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode