172 lines
4.9 KiB
ReStructuredText
172 lines
4.9 KiB
ReStructuredText
..
|
|
Copyright 2017 Canonical UK Ltd
|
|
|
|
This work is licensed under a Creative Commons Attribution 3.0
|
|
Unported License.
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
..
|
|
This template should be in ReSTructured text. Please do not delete
|
|
any of the sections in this template. If you have nothing to say
|
|
for a whole section, just write: "None". For help with syntax, see
|
|
http://sphinx-doc.org/rest.html To test out your formatting, see
|
|
http://www.tele3.cz/jbar/rest/rest.html
|
|
|
|
=================
|
|
Service Discovery
|
|
=================
|
|
|
|
Many optional services may now be deployed as part of an OpenStack Cloud,
|
|
with each service having a different optional features that may or may
|
|
not be enabled as part of a deployment.
|
|
|
|
Charms need a way to discover this information so that services can be
|
|
correctly configured for the options chosen by the charm user.
|
|
|
|
Problem Description
|
|
===================
|
|
|
|
Charms need to be able to determine what other services are deployed
|
|
within an OpenStack Cloud so that features can be enabled/disabled as
|
|
appropriate.
|
|
|
|
Examples include:
|
|
|
|
- notifications for ceilometer (really don't want notifications enabled
|
|
when ceilometer is not deployed).
|
|
|
|
- misc panels within the openstack dashboard (fwaas, lbaas, l3ha, dvr
|
|
etc... for neutron).
|
|
|
|
- notifications for designate (disable when designate is not deployed).
|
|
|
|
Services and features of services are determined by the API endpoint
|
|
charms that register them into the service catalog via the keystone charm.
|
|
|
|
Proposed Change
|
|
===============
|
|
|
|
The keystone charm will expose a new provides interface 'cloud-services'
|
|
which is a rich-ish description of the services deployed with registered
|
|
endpoints.
|
|
|
|
The identity-service relations would also advertise the same data as the
|
|
cloud-services relations so that charms already related to keystone don't
|
|
have to double relate (identity-service is a superset of cloud-services).
|
|
|
|
By default, a registered endpoint of type 'A' will result in service type
|
|
'A' being listed as part of the deployed cloud on this interface.
|
|
|
|
Services may also enrich this data by providing 'features' (optional)
|
|
alongside their endpoint registration - these will be exposed on the
|
|
cloud-service and identity-service relations.
|
|
|
|
Data will look something like (populated with real examples - key and
|
|
proposed values):
|
|
|
|
.. code-block:: yaml
|
|
|
|
services: ['object-store', 'network', 'volumev2', 'compute',
|
|
'metering', 'image', 'orchestration', 'dns']
|
|
|
|
Example - advertise features supported by the networking service, allowing
|
|
features to be enabled automatically in the dashboard:
|
|
|
|
.. code-block:: yaml
|
|
|
|
network: ['dvr', 'fwaas', 'lbaasv2', 'l3ha']
|
|
|
|
Example - allow ceilometer to know that the deployed object-store is radosgw
|
|
rather than swift:
|
|
|
|
.. code-block:: yaml
|
|
|
|
object-store: ['radosgw']
|
|
|
|
Values will be parseable as a json/yaml formatted list.
|
|
|
|
By using the basic primitive of tags, we get alot of flexibility with
|
|
type/feature being easily express-able.
|
|
|
|
Interface will be eventually consistent in clustered deployments -
|
|
all keystone units will present the same data.
|
|
|
|
Alternatives
|
|
------------
|
|
|
|
Each charm could query the keystone service catalog; however this is very
|
|
much a point in time check, and the service catalog may change after the
|
|
query has been made. In addition the keystone service catalog does not
|
|
have details on what optional features each service type may have enabled
|
|
and keystone services will be restarted during deployment as clusters
|
|
get built out etc.
|
|
|
|
Implementation
|
|
==============
|
|
|
|
Assignee(s)
|
|
-----------
|
|
|
|
Primary assignee:
|
|
james-page
|
|
|
|
Gerrit Topic
|
|
------------
|
|
|
|
Use Gerrit topic "service-discovery" for all patches related to this spec.
|
|
|
|
.. code-block:: bash
|
|
|
|
git-review -t service-discovery
|
|
|
|
Work Items
|
|
----------
|
|
|
|
Core (keystone charm):
|
|
|
|
- Add cloud-services relation to keystone charm
|
|
- Add service and feature discover handler to keystone charm
|
|
- Update keystone interface to advertise services and features in
|
|
keystone charm.
|
|
- Create cloud-services reactive interface
|
|
|
|
Enablement:
|
|
|
|
- Update ceilometer charm for radosgw discovery.
|
|
- Update openstack-dashboard charm to automatically enable panels
|
|
for deployed services and features.
|
|
- Update neutron-api charm for designate discovery.
|
|
- Update cinder charm for ceilometer discovery.
|
|
- Update glance charm for ceilometer discovery.
|
|
- Update neutron-api charm for ceilometer discovery.
|
|
- Update radosgw charm to advertise 'radosgw' feature.
|
|
- Update neutron-api charm to advertise networking features.
|
|
|
|
Repositories
|
|
------------
|
|
|
|
No new git repositories required.
|
|
|
|
Documentation
|
|
-------------
|
|
|
|
This change is internal for use across the OpenStack charms, no documentation
|
|
updates are required for end-users.
|
|
|
|
Security
|
|
--------
|
|
|
|
No security implications for this change.
|
|
|
|
Testing
|
|
-------
|
|
|
|
Implementation will include unit tests for all new code written; amulet
|
|
function tests will be updated to ensure that feature is being implemented
|
|
correctly across the charm set.
|
|
|
|
Dependencies
|
|
============
|
|
|
|
No external dependencies
|