Re: [openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client
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" 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 >wrote: >> >> >> On 13 March 2018 at 18:51, Eric K 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >http://
Re: [openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client
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 wrote: > > > On 13 March 2018 at 18:51, Eric K 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client
On 13 March 2018 at 18:51, Eric K 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. 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. 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 > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client
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. 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! 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev