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

Refactor Client Managers