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
dffe0f0463