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 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.
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 goalsthen 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
