On 2018-12-24 16:12:24 +1300 (+1300), Andrew Ruthven wrote: > [I'm not answering any of the questions, as I'm not in a position > to answer them!] > > On Sat, 2018-12-22 at 22:41 +0100, Thomas Goirand wrote: > > Now, an external resource which we don't control isn't going to > > change anything to the problem I just mentioned. Even worse: I > > don't see a public cloud provider making tempest available to > > us, as it would make their cloud dirty (ie: with maybe some > > remaining aftefacts after the script runs, some nasty tempest > > configuration that needs to be installed, etc.). > > I see no reason why you can't just run tempest against your > tenant. No need for the cloud provider to do anything. Agreed, it depends entirely on what test set you feed Tempest. Nothing about Tempest itself presumes administrative access. Add https://docs.openstack.org/python-tempestconf/latest/user/usage.html#non-admin-argument and you don't really need to know anything about the target environment to generate a Tempest configuration for it. > One of my colleagues is preparing a script that'll clean up any left > over tempest created resources... There's https://docs.openstack.org/tempest/latest/cleanup.html already, and if it doesn't meet your needs then please at least let the Tempest maintainers know why (or help make it useful for your particular case if you can). There's also https://git.openstack.org/cgit/openstack/ospurge/tree/README.rst which can be used by a non-admin service account to clean out all resources in a project, though that's a bit more of a sledgehammer approach. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature