dffe0f0463
openstacksdk is in the business of being an SDK for OpenStack. While it's tempting to support other services that people might want to run alongside their OpenStack cloud and register in their keystone catalog, doing so is just not feasible. At the same time, the 95% case is that the openstacksdk will be used for OpenStack services, so using entrpoints-based plugin loading as part of normal usage incurs a startup cost that can be rather high (it's based on the number of python packages installed on the system, not the number of plugins for openstacksdk) Add a method and a constructor parameter to Connection that allows people to programmatically enable support for additional non-OpenStack services. This introduce a new Service description class that maps service_type, Proxy class and optional service_type aliases. A subclass of Service could be provided by whoever is writing the Proxy class and associated Resoure objects, or the base class can be instantiated with type and proxy_class as arguments. While doing this, rework the loading of the official OpenStack services to use the Service descriptor objects. Add an OpenStackService subclass which does the importlib searching of the openstack module tree for proxy classes. This gets all of the module searching and loading into the openstack.services module and out of Connection. This should allow us to delete the metric service from the tree but provide people who want to use the metric service with openstacksdk a mechanism to do so. It also should provide a vehicle for people developing new not-yet-official services to develop their Resource and Proxy classes out of tree, and then move them in once they are official Change-Id: I6d1e0c45026a2e7b3c42983df9c0565b1c501bc3
6 lines
169 B
YAML
6 lines
169 B
YAML
---
|
|
features:
|
|
- |
|
|
Added a new method `openstack.connection.Connection.add_service` which
|
|
allows the registration of Proxy/Resource classes defined externally.
|