Hi Plamen, Lucas, sorry for late answer we have public holiday there. It was interesting reading. Thank you for introducing us "your concept" it looks really good, especially when you plane to test apps in vms. It could be probably adapted to more general purpose.
Only some names: config.file -> lexical parser -> variants object structure (tree) -> dictionary generator -> dicts with config. If I understand it correctly it would be great if your concept could operate with "variants object structure (tree)" it could save lots of compute time and generation of dictionaries will be driven by setup/test/clean relations as you described in test_traversal_algorithm.pdf. I have almost prepared some commit which allow split "lexical parser" from "dictionary generator". I see one may be big problem for general purpose how to save online state of real machine. There are lots of test which need to run on real machine because nested virtualization sometime have problem.. We had to sacrifice speed of testing due to better debugging of test results and repeatability of the results. It could be some combination let say "plugin" system because for testing apps in vms your concept could be really great. * Have you any Idea how to expand your concept to real hardware? config.file -> lexical parser -> variants object structure (tree) -> "plugin" -> dicts with Dict generators plugins could be configurable (slow portable python, "your concept", fast external SAT solver). * How far your are with "your concept"? * What you do you think about plugin system? Best regards, Jiří Župka ----- Original Message ----- > 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
