Open Stack

Hi All,

Sorry for late response, i kept this mail unread but forgot to
respond. reply inline.

On Fri, Mar 16, 2018 at 8:08 PM, Dougal Matthews <dougal at redhat.com> wrote:
>
>
> On 13 March 2018 at 18:51, Eric K <ekcs.openstack at gmail.com> wrote:
>>
>> Hi Mistral folks and others,
>>
>> I'm working on Congress tempest tests [1] for integration with Mistral. In
>> the tests, we use a Mistral service client to call Mistral APIs and
>> compare results against those obtained by Mistral driver for Congress.
>>
>> Regarding the service client, Congress can either import directly from
>> Mistral tempest plugin [2] or maintain its own copy within Congress
>> tempest plugin.

Maintaining own copy will leads to lot of issues and lot of duplicate
code among many plugins.

>I'm not sure whether Mistral team expects the service
>> client to be internal use only, so I hope to hear folks' thoughts on which
>> approach is preferred. Thanks very much!
>
>
> I don't have a strong opinion here. I am happy for you to use the Mistral
> service client, but it will be hard to guarantee stability. It has been
> stable (since it hasn't changed), but we have a temptest refactor planned
> (once we move the final tempest tests from mistraclient to
> mistral-tempest-plugin). So there is a fair chance we will break the API at
> that point, however, I don't know when it will happen, as nobody is
> currently working on it.

>From QA team, service clients are the main interface which can be used
across tempest plugins. For example, congress need many other service
clients from other Tempest Plugins liek Mistral. Tempest also declare
all their in-tree service clients as library interface and we maintain
them as per backward compatibility [3]. This way we make these service
clients usable outside of Tempest also to avoid duplicate
code/interface.

For Service Clients defined in Tempest plugins (like Mistral service
clients),  we suggest (strongly) the same process which is to declare
plugins's service clients as stable interface which gives 2 advantage:
1. By this you make sure that you are not allowing to change the API
calling interface(service clietns) which indirectly means you are not
allowing to change the APIs. Makes your tempest plugin testing more
reliable.

2. Your service clients can be used in other Tempest plugins to avoid
duplicate code/interface. If any other plugins use you service clients
means, they also test your project so it is good to help them by
providing the required interface as stable.

Initial idea of owning the service clients in their respective plugins
was to share them among plugins for integrated testing of more then
one openstack service.

Now on usage of service clients, Tempest provide a better way to do so
than importing them directly [4]. You can see the example for Manila's
tempest plugin [5]. This gives an advantage of discovering your
registered service clients in other Tempest plugins automatically.
They do not need to import other plugins service clients. QA is hoping
that each tempest plugins will move to new service client registration
process.

Overall, we recommend to have service clients as stable interface so
that other plugins can use them and test your projects in more
integrated way.

>
> I have cc'ed Chandan - hopefully he can provide some input. He has advised
> me and the Mistral team regarding tempest before.
>
>>
>>
>> Eric
>>
>> [1] https://review.openstack.org/#/c/538336/
>> [2]
>>
>> https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_tem
>> pest_tests/services/v2/mistral_client.py
>>
>>

..3 http://git.openstack.org/cgit/openstack/tempest/tree/tempest/lib/services
..4 https://docs.openstack.org/tempest/latest/plugin.html#get_service_clients()
..5 https://review.openstack.org/#/c/334596/34

-gmann

>>
>> __________________________________________________________________________
>> 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
>