Hi Chris
First of all it seems that we aim the same target, and that is a good start, :) Word "engine" hides too many details, and i want to make it more clear to see every parts of this tool chain instead of a big black box putting all stuff in.So maybe something else would be appropriate, and i guess we can talk about it later with this naming issue As you mentioned when the tests are done is determined by the "parser", while it may be not necessarily working like that. Those test cases are pared and loaded in one action in "parer", then are executed one by one in "runner". I did ignore the db operation, the "report" generated from the results stored in db, i will add "db" to the diagram ,and make the chain like this: functest->db->report Dashboard is somewhere showing the report from my point of view, a better presentation than raw data of the report text with fancy pages if we have time and resource to design and develop,;) BR Leo Wang On 2016/8/30 18:35, Christopher Price wrote: Hi Leo, Looking at the diagram I might have expected to see things a little differently, it may just be representation but let’s discuss some points to see if we are on the same page. “Parser” -> rename to “dovetail engine” or something this is where all the dovetail specific stuff needs to get done so it’s worth labelling it explicitly. I also would expect to see the “parser” entity execute the download as listed. But… then I would expect it to be the “parser” entity that is calling the “runner” function according to the specific test cases/suites that are required for this run so I would have the arrow from the “parser” to the runner function that interacts with the test containers. Additionally, I would think that while the “runner” will result in updates to the database and dashboard with the atomic information generated by the test containers, it would not be until the “parser” determines that the tests are done that a report would be generated as a function of the dovetail toolchain. It may be worth showing the yardstick/functest entities updating the database directly, to be consumed by the dovetail process in the future for generating the reports. In that same way I might think the dashboard and report are two separate items that are not necessarily chained. Dashboard is the result of filling the DB whereas the report is something explicitly generated by dovetail. Does that make sense; do you see it the same way? / Chris From: Leo Wang <[email protected]><mailto:[email protected]> Date: Tuesday 30 August 2016 at 09:29 To: Christopher Price <[email protected]><mailto:[email protected]>, Tianhongbo <[email protected]><mailto:[email protected]>, TECH-DISCUSS OPNFV <[email protected]><mailto:[email protected]> Subject: Re: [opnfv-tech-discuss] [dovetail]new topic- script for validating the test cases Hi Chris Glad to see your attention, and your great question. I would like to discuss this architecture with anyone in which who interested to improve the approach. May be on the dovetail weekly meeting or any proper circumstance. I choose the docker to pack all dovetail stuff into a image, the best practice to deploy and execute the scripts, and the dovetail container will be a "sibling" to the functest/yardstick. It's not simply run functest/yardstick in this container , so we literally are re-using those existing docker containers As for the test report, it's true we should focus on a specific scope, and i will remove SDN/VNF related information to make it more clear. BR Leo Wang On 2016/8/29 18:08, Christopher Price wrote: Hi Leo, Thanks for starting to sketch this out. On the architecture I think it would be worth a discussion with the testing teams on the best approach. Using a Docker container makes sense as it follows the best practices our test teams have identified. I’m not so sure about creating a new Docker for DoveTail that runs functest and YardStick etc, why not simply re-use those existing Docker containers? On the test report. We have identified our initial SUT will focus on VIM+VNFi thus component specific test reports such as ODL, ONOS are not in scope at this time. I suggest focusing this list only on relevant SUT test reporting and removing the extra information. / Chris From: <[email protected]><mailto:[email protected]> on behalf of Leo Wang <[email protected]><mailto:[email protected]> Date: Monday 29 August 2016 at 05:14 To: Tianhongbo <[email protected]><mailto:[email protected]>, TECH-DISCUSS OPNFV <[email protected]><mailto:[email protected]> Subject: Re: [opnfv-tech-discuss] [dovetail]new topic- script for validating the test cases Hi I have some thoughts on this topic, and create a page about it. There is a simple diagram showing the architecture of the scripts and some information about the test results from upstream testing project Anyone interested in this topic can share your ideas within the page, expect more discussion https://wiki.opnfv.org/pages/viewpage.action?pageId=7766287 On 2016/8/26 10:06, Tianhongbo wrote: Hi: I will put this on the dovetail agenda. Best Regards hongbo From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of wang lei Sent: 2016年8月26日 9:50 To: [email protected]<mailto:[email protected]> Subject: Re: [opnfv-tech-discuss] [dovetail]new topic- script for validating the test cases scripts are the key to make sure that all these testcases work as an organic whole, i would like to participate in this topic, expect more discussion. BR Leo Wang On 2016/8/17 15:06, Tianhongbo wrote: Hi all dovetailers: The dovetail team are working on the test cases design, requirements from C&C(sfc,L3VPN and IPV6). I would like to arise the new topic: script for validating the test cases. As required by the C&C, the dovetail needs to prepare the test cases and scripts for validate the test cases. the scripts are related to the codes managements. Best Regards hongbo _______________________________________________ opnfv-tech-discuss mailing list [email protected]<mailto:[email protected]> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list [email protected]<mailto:[email protected]> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss -- BR Leo Wang -- BR Leo Wang
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
