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" <[email protected]> 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 <[email protected]> >wrote: >> >> >> On 13 March 2018 at 18:51, Eric K <[email protected]> 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: >>>[email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>[email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
