Open Stack

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