[openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

Lajos Katona lajos.katona at ericsson.com
Fri Sep 11 06:50:36 UTC 2015


Hi Matthew,

Thanks for the help, this helped a lot a start the work.

regards
Lajos

On 09/10/2015 04:13 PM, Matthew Treinish wrote:
> On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote:
>> Hi,
>>
>> I just noticed that from tag 6, the test plugin interface considered ready,
>> and I am eager to start to use it.
>> I have some questions:
>>
>> If I understand well in the future the plugin interface will be moved to
>> tempest-lib, but now I have to import module(s) from tempest to start to use
>> the interface.
>> Is there a plan for this, I mean when the whole interface will be moved to
>> tempest-lib?
> The only thing which will eventually move to tempest-lib is the abstract class
> that defines the expected methods of a plugin class [1] The other pieces will
> remain in tempest. Honestly this won't likely happen until sometime during
> Mitaka. Also when it does move to tempest-lib we'll deprecate the tempest
> version and keep it around to allow for a graceful switchover.
>
> The rationale behind this is we really don't provide any stability guarantees
> on tempest internals (except for a couple of places which are documented, like
> this plugin class) and we want any code from tempest that's useful to external
> consumers to really live in tempest-lib.
>
>> If I start to create a test plugin now (from tag 6), what should be the best
>> solution to do this?
>> I thought to create a repo for my plugin and add that as a subrepo to my
>> local tempest repo, and than I can easily import stuff from tempest, but I
>> can keep my test code separated from other parts of tempest.
>> Is there a better way of doing this?
> To start I'd take a look at the documentation for tempest plugins:
>
> http://docs.openstack.org/developer/tempest/plugin.html
>
>  From tempest's point of view a plugin is really just an entry point that points
> to a class that exposes certain methods. So the Tempest plugin can live anywhere
> as long as it's installed as an entry point in the proper namespace. Personally
> I feel like including it as a subrepo in a local tempest tree is a bit strange,
> but I don't think it'll cause any issues if you do that.
>
>> If there would be an example plugin somewhere, that would be the most
>> preferable maybe.
> There is a cookiecutter repo in progress. [2] Once that's ready it'll let you
> create a blank plugin dir that'll be ready for you to populate. (similar to the
> devstack plugin cookiecutter that already exists)
>
> For current examples the only project I know of that's using a plugin interface
> is manila [3] so maybe take a look at what they're doing.
>
> -Matt Treinish
>
> [1] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/test_discover/plugins.py#n26
> [2] https://review.openstack.org/208389
> [3] https://review.openstack.org/#/c/201955
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150911/6814bdf7/attachment.html>


More information about the OpenStack-dev mailing list