Metadata-Version: 2.4
Name: vigie-tempest-plugin
Version: 0.0.1
Summary: OpenStack Vigie Tempest Plugin
Home-page: https://www.openstack.org/
Author: OpenStack
Author-email: openstack-discuss@lists.openstack.org
Keywords: setup,distutils
Classifier: Environment :: OpenStack
Classifier: Intended Audience :: Information Technology
Classifier: Intended Audience :: System Administrators
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Requires-Python: >=3.9
License-File: LICENSE
Requires-Dist: openstacksdk>=0.101.0
Requires-Dist: tempest>=30.0.0
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: home-page
Dynamic: keywords
Dynamic: license-file
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

# Vigie Tempest Plugin

Tempest plugin providing the functional (scenario) tests for
[Vigie](https://salsa.debian.org/openstack-team/services/vigie), an
OpenStack operator API aimed at easing the administration of an
existing deployment.

Vigie lets operators run daily tasks on a live cloud through queued
worker tasks: purging all resources of a project, suspending or
unsuspending a project, deleting resources, and more. The tests in
this plugin build real resources on a live OpenStack cloud — servers,
networks, volumes, images, Heat stacks, and more — then drive the
Vigie API to make sure the tasks clean them all up as expected.

## How it works

Once the package is installed (e.g. `pip install .` or the
`vigie-tempest-plugin` Debian package), Tempest discovers it through
the `tempest.test_plugins` entry point declared in `setup.cfg`, and
`tempest run` picks up its tests automatically.

Every test class inherits from `VigieScenarioTest`, which uses
Tempest's dynamic credentials: **a fresh project and user are created
for each test class**, so the tests never depend on, nor pollute,
pre-existing resources. Parallel stestr workers therefore run against
fully isolated projects.

## Resource creation helpers

The helpers live in
`vigie_tempest_plugin/tests/scenario/manager.py`. Each of them creates
a resource, waits for it to reach a ready state, and registers its
teardown right after the creation so Tempest's cleanup unwinds in
reverse dependency order.

The client strategy is "reuse before re-inventing":

1. Tempest's own primitives and clients when they exist (networks,
   subnets, routers, servers, keypairs, floating IPs, volumes,
   snapshots, images);
2. [openstacksdk](https://docs.openstack.org/openstacksdk/) for the
   services Tempest has no client for (Heat stacks for now), built
   from the dynamic credentials of the current test class;
3. plugin-local clients only when neither works (future services).

Available helpers:

- `create_routable_network_topology()` — private network, subnet,
  router, router interface, external gateway, server on the subnet,
  floating IP on the server, in that order;
- `create_server_with_keypair()` — standalone server on the tenant
  network;
- `create_private_image()` — private Glance image fed with random
  bytes;
- `create_volume()` / `create_volume_snapshot()` — inherited from
  `tempest.scenario.manager`;
- `create_stack()` — Heat stack through openstacksdk.

## Repository structure

```
vigie-tempest-plugin/
├── setup.cfg                       pbr packaging + tempest entry point
├── setup.py                        pbr shim
├── tox.ini                         py3 and pep8 environments
├── .stestr.conf                    stestr test discovery
├── requirements.txt                runtime dependencies
├── test-requirements.txt           test-time dependencies
├── debian/                         Debian packaging (openstack-pkg-tools)
└── vigie_tempest_plugin/
    ├── plugin.py                   TempestPlugin hooks: load_tests(),
    │                               register_opts(), get_opt_lists()
    ├── config.py                   service_available.vigie + [vigie]
    │                               option group
    └── tests/
        └── scenario/
            ├── manager.py          VigieScenarioTest base class and
            │                       the resource creation helpers
            └── (the test classes   one small class per resource
                come here)          kind, 1-2 tests each
```

## Configuration

Enable the service in `tempest.conf`:

```ini
[service_available]
vigie = True
```

The helpers reuse the standard Tempest configuration groups (identity,
compute, network, volume, image); no plugin-specific option is needed
yet. The reserved `[vigie]` group will host the options of the Vigie
API client once the tests start driving the API.

## Status

Work in progress: the base class and the resource creation helpers
have landed; the test classes exercising the Vigie API come next.

