Open Stack

On Thu, Nov 30, 2017 at 12:11 AM, Andrea Frittoli
<andrea.frittoli at gmail.com> wrote:
>
>
> On Wed, Nov 29, 2017 at 2:28 PM Peng Liu <pliu at redhat.com> wrote:
>>
>> Hi Team,
>>
> Hi Peng
>
>>
>> I have a question regarding to the API coverage of Patrole. Currently,
>> Patrole as a Tempest plugin heavily relys on the Tempest code. However,
>> Tempest only contains the API tests for the most common APIs of the most
>> common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone).
>>
>> So I want to know if it is possible to extend Patrole to:
>> 1) test the APIs of the common projects which was not yet covered in
>> Tempest.
>>
>> 2) test projects which was not covered in Tempest?

In case there is any gap, Patrole will not tests the API like Tempest
does. It will test only policy enforcement on API. Tempest way to test
API is different than what Patrole does. I hope you mean the same here
which means to extend the coverage of other projects' API policy tests
in Patrole.

>
>
> You can use the Patrole framework to test services not covered by Tempest by
> taking advantage of Tempest plugin mechanism.
> Patrole itself is a Tempest plugin. If you install the plugin of a service
> that includes a service client, you should be able to use it to write
> Patrole tests for that service.
> I believe this has not been done yet by any project though, so there may be
> a few technical bits to be sorted out.
>
> I don't think Patrole itself will have to be extended, however Patrole does
> not yet include stable APIs.
> If you're going to use Patrole APIs in your project you need to be aware
> that there may be backward incompatible changes happening without a
> deprecation period.
>
> There are several options on where to host such tests: in a dedicated
> plugin, in the Tempest plugin for the service or in Patrole itself.
> The latter would probably suffer from the same scalability issues that lead
> us to create the plugin mechanism to begin with.

Yea, I remember we talked about it in some of previous PTG or Summit
also. I feel having Patrole tests for other projects in separate
plugin is not the best way. It will lead to have 2 tempest plugin on
each projects side (one for Tempest and second for Patrole).  I prefer
the solution to have all tests in Patrole repo itself if possible.
Scalability might be issue with this but Patrole test are just policy
test so should not be hard as Tempest tests.
But that is something we need to discussed in detail considering all
cases of maintenance and current resources bandwidth in Patrole.

We have 2 items here to make it possible:
1. Decide the best way to tests Policy for other projects which are
not covered in Patorle. Options are 1. "Separate Patrole Plugin per
projects" 2. "In Projects Tempest Plugin" 3. "In Patrole itself".

2. If we go for Plugin approach then. make Patrole framework stable.

I do not find these 2 items very complex and can be done soon.

-gmann

>
> Andrea Frittoli (andreaf)
>
>>
>>
>> Thanks,
>> --
>> Peng Liu
>> __________________________________________________________________________
>> 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
>
>
> __________________________________________________________________________
> 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
>