Merge "Adds spec for Service Catalog standardization"
This commit is contained in:
commit
90c8ccdf80
|
@ -0,0 +1,256 @@
|
||||||
|
===============================
|
||||||
|
Service Catalog Standardization
|
||||||
|
===============================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/keystone/+spec/service-catalog-standards
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
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::
|
||||||
|
|
||||||
|
<service_type>:<service_name>:<endpoint_type>.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
A Vision of the Ideal Service Catalog
|
||||||
|
=====================================
|
||||||
|
|
||||||
|
The following is a vision of where we want to get to with the service
|
||||||
|
catalog in OpenStack.
|
||||||
|
|
||||||
|
1. Querying type='volume' in any service catalog on any cloud returns
|
||||||
|
an unversioned URL for that service. This is a contract we can
|
||||||
|
depend on.
|
||||||
|
|
||||||
|
2. All OpenStack server components find the operational urls for other
|
||||||
|
OpenStack services with the catalog.
|
||||||
|
|
||||||
|
3. The service types used in the catalog, such as ``volume`` or ``compute``,
|
||||||
|
defined in server components. This definition ensures that standardization
|
||||||
|
propagates, as clouds will not work if their service catalog is not
|
||||||
|
defined correctly.
|
||||||
|
|
||||||
|
4. There are Tempest tests for standard service catalog, and it's a
|
||||||
|
DefCore requirement that standard service catalog entries are
|
||||||
|
defined.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- Name and type are meaningless, misunderstood, and poorly documented.
|
||||||
|
|
||||||
|
- Regions are not consistently named or used. The way regions are structured
|
||||||
|
are a pain for SDKs, because it requires a lot of traversing. Encourage
|
||||||
|
clear provider documentation and guidance for this naming.
|
||||||
|
|
||||||
|
- The versions in URLs are inconsistent (see what we want to solve for above).
|
||||||
|
|
||||||
|
- The tying between auth and getting a service catalog seems unnecessary. See
|
||||||
|
roles example above. A user should be able to get a list of all the services
|
||||||
|
and endpoints in a single, preferably unauthenticated, call.
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- Ensure each service's API has a version request (current standard is a GET
|
||||||
|
call to /). However, keystoneauths's session can't use that to discover
|
||||||
|
versions because the URL returned by the Identity service for another
|
||||||
|
configured service is the versioned endpoint. The version is embedded in the
|
||||||
|
URL. We should have the Identity service discover version number with each
|
||||||
|
services' API itself.
|
||||||
|
|
||||||
|
- Remove ``project_id`` template from endpoints, acknowledging that future clients
|
||||||
|
will have to account for this change.
|
||||||
|
|
||||||
|
- Ensure DevStack examples are consistent and can be used as an exemplary
|
||||||
|
best practice.
|
||||||
|
|
||||||
|
- Ensure Tempest works with new catalog.
|
||||||
|
|
||||||
|
- Write a tempest test that uses JSON Schema for the service catalog.
|
||||||
|
|
||||||
|
- Provide the standard project and service names in the governance repository
|
||||||
|
through the `projects.yaml` file. However, enable flexibility in the "name"
|
||||||
|
for providers to offer multiple services.
|
||||||
|
|
||||||
|
- Cause project's interactions with the service catalog to be standard so that
|
||||||
|
for example, the nova project does not need three configuration variables to
|
||||||
|
specify how nova can interact with the cinder service catalog entries.
|
||||||
|
|
||||||
|
- Ensure that the publicURL, adminURL, and internalURL have known use cases.
|
||||||
|
Work with the operator community to understand whether those can be
|
||||||
|
consolidated when presenting the catalog to an end user.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Anne Gentle annegentle
|
||||||
|
Augustina Ragwitz
|
||||||
|
Sean Dague sdague
|
||||||
|
Dolph Matthews dolphm
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- existence of service_type: required
|
||||||
|
- value type of service_type: string (reference for value from
|
||||||
|
governance/projects.yaml file)
|
||||||
|
- extra data: acceptable because of the need for transition for providers
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
.. Summit session:
|
||||||
|
https://libertydesignsummit.sched.org/event/194b2589eca19956cb88ada45e985e29
|
||||||
|
|
||||||
|
Additional Reading
|
||||||
|
==================
|
||||||
|
|
||||||
|
http://docs.openstack.org/developer/keystone/configuration.html?highlight=catalog#service-catalog
|
||||||
|
|
||||||
|
http://docs.openstack.org/juno/config-reference/content/list-of-compute-config-options.html
|
||||||
|
|
||||||
|
http://dolphm.com/openstack-keystone-service-catalog/
|
||||||
|
|
||||||
|
https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver
|
||||||
|
|
||||||
|
https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Entry_Points
|
||||||
|
|
||||||
|
https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Liberty
|
||||||
|
- Introduced
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
Loading…
Reference in New Issue