add bp:client-manager-refactor
Refactor tempest client manager classes Change-Id: I6469148f539c53680ed03835fe15b19912f83de9
This commit is contained in:
Andrea Frittoli
Andrea Frittoli
parent
dc19407c77
commit
6c500e5629
|
|
@ -0,0 +1,163 @@
|
|||
::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
..
|
||||
|
||||
========================
|
||||
Refactor Client Managers
|
||||
========================
|
||||
|
||||
https://blueprints.launchpad.net/tempest/+spec/client-manager-refactor
|
||||
|
||||
The current client managers depends on a relatively large number of
|
||||
configuration items, that is the combination of all clients parameters.
|
||||
This makes its migration to tempest-lib troublesome.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
We have several plans about the client manager:
|
||||
|
||||
- make it as stable interface in tempest.lib. This will help in turn the
|
||||
migration of credential providers and service clients to the .lib namespace.
|
||||
And it will give people writing tempest plug-in a home for their custom
|
||||
service clients
|
||||
- change it so that it is possible for plug-in developer to add their service
|
||||
clients dynamically into the client manager, so we can have a consistent
|
||||
way of accessing test clients from tests
|
||||
|
||||
The current client managers depends on CONF, and it's structure does not
|
||||
easily allow for runtime registration of extra clients.
|
||||
|
||||
For instance, in *Manager* class:
|
||||
|
||||
::
|
||||
|
||||
self.network_client = NetworkClient(
|
||||
self.auth_provider,
|
||||
CONF.network.catalog_type,
|
||||
CONF.network.region or CONF.identity.region,
|
||||
endpoint_type=CONF.network.endpoint_type,
|
||||
build_interval=CONF.network.build_interval,
|
||||
build_timeout=CONF.network.build_timeout,
|
||||
|
||||
..
|
||||
|
||||
Another issue with the current structure is that new API versions lead to
|
||||
proliferation of client attributes in the client manager classes. With
|
||||
service clients being split into pieces, the size of the client manager
|
||||
grows accordingly.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Split the client manager in two parts.
|
||||
|
||||
The first part provides lazy loading of clients, and it does not depend on
|
||||
tempest CONF, as it is planned for migration to tempest.lib.
|
||||
It covers the six client groups for the six core services covered by tempest in
|
||||
the big tent. It exposes an interface to register further service clients.
|
||||
|
||||
Lazy loading of clients provides protection against clients that try to
|
||||
make API calls at __init__ time; it also helps in running tempest with the
|
||||
minimum amount of CONF required for the clients in use by a specific test run.
|
||||
|
||||
The second part passes tempest CONF values to the first one. It registers
|
||||
any non-core client, whether still in tempest tree or coming from a plug-in.
|
||||
|
||||
The client registration interface could look like:
|
||||
|
||||
::
|
||||
|
||||
def register_clients_group(self, name, service_clients, description=None,
|
||||
group_params=None, **client_params):
|
||||
"""Register a client group to the client manager
|
||||
|
||||
The client manager in tempest only manages the six core client.
|
||||
Any extra client, provided via tempest plugin-in, must be registered
|
||||
via this API.
|
||||
|
||||
All clients registered via this API must support all parameters
|
||||
defined in common parameters.
|
||||
|
||||
Clients registered via this API must ensure uniqueness of client
|
||||
names within the client group.
|
||||
|
||||
:param name: Name of the client group, e.g. 'orchestration'
|
||||
:param service_clients: A list with all service clients
|
||||
:param description: A description of the group
|
||||
:param group_params: A set of extra parameters expected by clients
|
||||
in this group
|
||||
:param client_params: each is a set of client specific parameters,
|
||||
where the key matches service_client.__name__
|
||||
"""
|
||||
|
||||
..
|
||||
|
||||
The tempest plugin ``TempestPlugin`` interface is extended with a method to
|
||||
return the service client data specific to a plugin. Each plugin defines
|
||||
a new service clients group and the relevant data.
|
||||
|
||||
Service Clients data is stored in a singleton ``ServiceClientsData``.
|
||||
``ServiceClientsData`` is instantiated by the ``TempestTestPluginManager``,
|
||||
which obtains the service client data from each plugin and registers it.
|
||||
|
||||
Client managers used by tests consume the service client data singleton,
|
||||
and dynamically defines a set of attributes which can be used to access the
|
||||
clients.
|
||||
|
||||
Attributes names are statically defined for now. They will be the same names as
|
||||
now, to minimize the impact on the codebase. For plugins, attributes names
|
||||
include the group name, to avoid name conflicts across service clients that
|
||||
belong to different plugins.
|
||||
|
||||
In future we may define a standard naming convention for attribute
|
||||
names and to enforce it by deriving names automatically. Future names may not
|
||||
contain the '_client' suffix, to save space and allow for always specifying
|
||||
the client provider in test code, so to make the code more readable.
|
||||
This naming convention will not be implemented as part of this spec.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Keep the manager on tempest side, and have big tent teams write their own
|
||||
managers. Carry long list of clients as parameters in cred providers and
|
||||
other parts of tempest
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Andrea Frittoli <andrea.frittoli@hpe.com>
|
||||
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion:
|
||||
Newton-1
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
- Core functionality in manager part1, with unit test coverage and migration
|
||||
of one client group
|
||||
- Migration of other client groups (one per patch)
|
||||
- Implementation of the registration interface (does not depend on step 2)
|
||||
- Registration of non-core clients from tempest tree
|
||||
- Registration of non-core clients from plugins
|
||||
- Separate manager part1 into it's own module, and include maanger.py along
|
||||
|
||||
Work has stared on this: Change-id I3aa094449ed4348dcb9e29f224c7663c1aefeb23
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue