----- Original Message ----- > On 05/02/2014 05:35 PM, Jiri Zupka wrote: > > 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. > > I was thinking the same about the more general purpose but even if we > start from something specific we can expand afterwards. This could be > better instead of taking one giant step all the way to the end goal. > > > 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". > > That's great! I will take a look at your commit as soon as it is > available for reading somewhere. At the moment the way we do it is with > minimum patching of the virt-test, performing parsing all tests in the > normal way and then storing them in the directed graph structure which > is of course memory and computation consuming. One of the reason for my > wish to try and integrate it in virt-test is exactly first because it > can be used for more general purpose and second because we could put it > inside the generator reducing all of this performance penalty. The idea > about the variants object structure (tree) is indeed what I was hoping > for, my only concern will be in implementing more of a directed graph > traversal there.
I try to send new patch as fast as possible, but it I have quite lots of work. I hope it will be soon. > > > 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? > > We already have implementation which uses LVM for offline states and > QCOW2 savevm/loadvm for online states which is used for virtual > machines. The question about real machines is indeed a good question. By > the plugin system you mean to make this traversal optional so that it > can be switched off on real machines? Or do you mean something else? I > am thinking that even if we expand the concept to online machines it is > already a step in the better direction. Yes, I think first variant, switchable dict generator. > > > Best regards, > > Jiří Župka > > Thank you for taking a look at the concept :) It is already implemented > but needs to be migrated in the variants object structure and I guess > made available only for virtual machines. Any idea on expading it > successfully to real machine is more than welcome. > > > ----- 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
