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):
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:
network: ['dvr', 'fwaas', 'lbaasv2', 'l3ha']
Example - allow ceilometer to know that the deployed object-store is radosgw rather than swift:
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.
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
