[openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client

Eric K ekcs.openstack at gmail.com
Thu Mar 29 00:47:40 UTC 2018

Thank you, Dougal and Ghanshyam for the responses!

What I can gather is: service client registration > import service client
> retaining copy.
So the best thing for Congress to do now is to import the service client.

On 3/17/18, 9:00 PM, "Ghanshyam Mann" <gmann at ghanshyammann.com> wrote:

>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>
>> 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
>>> approach is preferred. Thanks very much!
>> I don't have a strong opinion here. I am happy for you to use the
>> 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
>> (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
>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
>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
>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
>> me and the Mistral team regarding tempest before.
>>> Eric
>>> [1] https://review.openstack.org/#/c/538336/
>>> [2]
>>> pest_tests/services/v2/mistral_client.py
>..5 https://review.openstack.org/#/c/334596/34
>>> 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
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list