Bases: keystone.catalog.core.CatalogDriverV8
Retrieve and format the V2 service catalog.
Parameters: |
|
---|---|
Returns: | A nested dict representing the service catalog or an empty dict. |
Retrieve and format the current V3 service catalog.
Parameters: |
|
---|---|
Returns: | A list representing the service catalog or an empty list |
Bases: sqlalchemy.ext.declarative.api.Base, keystone.common.sql.core.DictBase
Bases: sqlalchemy.ext.declarative.api.Base, keystone.common.sql.core.ModelDictMixin
Endpoint Groups table.
Bases: sqlalchemy.ext.declarative.api.Base, keystone.common.sql.core.ModelDictMixin
project-endpoint relationship table.
Bases: sqlalchemy.ext.declarative.api.Base, keystone.common.sql.core.ModelDictMixin
Project to Endpoint group relationship table.
Bases: keystone.common.manager.Driver
A backend that generates endpoints for the Catalog based on templates.
It is usually configured via config entries that look like:
catalog.$REGION.$SERVICE.$key = $value
and is stored in a similar looking hierarchy. Where a value can contain values to be interpolated by standard python string interpolation that look like (the % is replaced by a $ due to paste attempting to interpolate on its own:
When expanding the template it will pass in a dict made up of the conf instance plus a few additional key-values, notably tenant_id and user_id.
It does not care what the keys and values are but it is worth noting that keystone_compat will expect certain keys to be there so that it can munge them into the output format keystone expects. These keys are:
- name - the name of the service, most likely repeated for all services of
- the same type, across regions.
adminURL - the url of the admin endpoint
publicURL - the url of the public endpoint
internalURL - the url of the internal endpoint
Retrieve and format the V2 service catalog.
Parameters: |
|
---|---|
Returns: | A nested dict representing the service catalog or an empty dict. |