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

[Marc Koderer]

Am 14.09.2015 um 10:01 schrieb Lajos Katona :

> Hi Matthew,
> 
> Finally I made it working, so now I have a dummy plugin.
> 
> Few questions, remarks:
> - For me it was little hard to merge my weak knowledge from python packaging 
> with the documentation for tempest plugins, do you mind if I push an example 
> to github, and I add the link to that to the documentation.

Can we add it directly into the documentation? I am fine with more code 
snippets there and
external links can be broken over time.

> - From this point the generation of the idempotent id is not clear for me. I 
> was able to use the check_uuid.py, and as I used a virtenv, the script edited 
> the .tox/venv/local/lib/python2.7/site-packages/dummyplugin/ file.
> Would be good maybe to add an extra path option to the check_uuid.py to make 
> it possible to edit the real source files in similar cases not the ones in 
> the venv.

Idempotent id’s aren’t covered in the first drop of tempest plugin interface.
I am wondering if there is a need from refstack..?

Regards
Marc

> Regards
> Lajos
> 
> On 09/11/2015 08:50 AM, Lajos Katona wrote:
>> 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-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for 

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

[Lajos Katona]

Hi Matthew,

Finally I made it working, so now I have a dummy plugin.

Few questions, remarks:
- For me it was little hard to merge my weak knowledge from python 
packaging with the documentation for tempest plugins, do you mind if I 
push an example to github, and I add the link to that to the documentation.


- From this point the generation of the idempotent id is not clear for 
me. I was able to use the check_uuid.py, and as I used a virtenv, the 
script edited the 
/.tox/venv/local/lib/python2.7/site-packages/dummyplugin// file.
Would be good maybe to add an extra path option to the check_uuid.py to 
make it possible to edit the real source files in similar cases not the 
ones in the venv.


Regards
Lajos

On 09/11/2015 08:50 AM, Lajos Katona wrote:

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lajos Katona]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lajos Katona]

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?


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?

If there would be an example plugin somewhere, that would be the most 
preferable maybe.


Thanks in advance for the help.

Regards
Lajos

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matthew Treinish]

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


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev