Ok, I finally had the time to read your documents. Quite the thought provoking read, in fact :)
The base concepts are solid, we really want to optimize test setup/cleanup time, so using the test node transverse algorithm and mechanisms to store states makes a ton of sense. I guess I tried to stay away from qcow2 snapshots because I did not want to rely heavily on part of the very functionality that is being tested (besides good ol' copy is way simpler), but I think it is time to abandon this fear. The biggest concern here is how much of that involved machinery has to be learned by the virt test developer and how much is transparent. See, virt test developers (part of the intended audience) are very smart, but are short in time and energy to grasp fairly complex concepts just to write tests. If all the resolution of variants and steps is transparent and people only have to learn a couple of new keywords, I'd say that is fine. Anyway, that's one impressive, state of the art work. Kudos to you and your team! As for me, I'm working on a simple implementation for our experimental test framework. If you want to take a look: https://github.com/avocado-framework/avocado/pull/60 Cheers, Lucas On Wed, Apr 30, 2014 at 8:57 AM, Plamen Dimitrov <[email protected]>wrote: > On 04/29/2014 07:12 PM, Plamen Dimitrov wrote: > >> On 04/29/2014 06:00 PM, Jiri Zupka wrote: >> >>> Please show us your implementation if it match new implementation goals >>>>> > >then >>>>> > >it could be used. >>>>> > > >>>>> >>>> >> I can prepare a couple of files with minimalistic explanation (perhaps >> one with PDF for visualization which in this case will prove to be useful) >> but it is important to mention that it could be a work-intensive change. >> However, in my opinion it will be worth taking a look at least from the >> perspective of generating new ideas. >> > > As promised, here are the two documents that describe what help us have > full control over how tests are run after they are parsed - from their > order (including any automatic order as scheduling criteria) to automatic > addition of tests (in our case this is tests that are dependencies of the > already selected tests but it might as well be an alternative to the > current problem of Cartesian parsing inside a test). > > Since we don't have a really large number of tests I would be glad on any > critics that Jiri would like to provide so that we try to find some > solutions for that too. The first document (txt) describes the structure > and the second (pdf) describes the test traversal. > > Both docs shouldn't take more than 15 minutes to read through. > > Best, > Plamen > > _______________________________________________ > Virt-test-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/virt-test-devel > > -- Lucas
_______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
