----- Original Message ----- > On 04/29/2014 10:24 AM, Jiri Zupka wrote: > > > > > > ----- Original Message ----- > >> Hi guys, > >> > >> Since all possible changes in the Cartesian configuration format concern > >> our tests quite much, I want to share my opinion on some of the point > >> below. > >> > >> On 04/29/2014 04:55 AM, Lucas Meneghel Rodrigues wrote: > >>> From the feedback gathered so far, the work items are: > >>> > >>> 1) Complexity > >>> > >>> Solution: Implement Paolo's RFC outlined here: > >>> > >>> https://www.redhat.com/archives/virt-test-devel/2014-February/msg00073.html > >>> > >>> > >>> Would be a start > >>> > >> > >> Paolo's proposal is good in the fact that it is an extension of the > >> currently available functionality. My main concern here is losing the > >> original meaning of "@" which I find rather useful. I think you will all > >> agree with me that short names instead of lengthy line-breaking strings > >> improve readability where desired. Can we perhaps keep the original > >> meaning of "@" at use another non-reserved character for this purpose? > >> It would be better than changing its meaning and finding another > >> character for name shortening for sure since people (and scripts) are > >> already accustomed to the current meaning. In this way we extend without > >> harming what we already have which is by no means useless. My second > >> point here would be that this is not really reduction of complexity, > >> since the general format is preserved and the only thing we do is even > >> add more complexity, however I guess for the better good. > > > > There is implemented default variants through variants metadata and through > > @. > > but it allows only one default from variants. Could be easy fixed. > > > > take a look in cartesian_config line 205 more accurately 218 > > > > variants virt_system [ default=linux ]: > > For enabling default metadata is necessary use generator switch "-d" or by > > python function "defaults" parameter. > > Interesting, maybe we could go with what is already available. > > > Paolo's proposal is good too. The Proposal don't need switch -d. > > > >> > >>> 2) Frailty > >>> > >>> Solution: Make the parser able to tell people wether they have messed > >>> up their indentation, and be loud and fail instead of silently > >>> ignoring the non-perfectly-aligned data. > >> > >> I completely agree with this. > > > > I absolutely agree with this,however, it loudly raise exception with wrong > > indentation in new implementation, if I'm right. We have to fix lots of > > indentation problem when we start using new implementation.
Sorry for using wrong time.. We had to fix lots of indentation problem when we started use (last)new implementation. This implementation should raise exception. > > Absolutely. That is the plan, in fact. I'm sure a lot of small errors > would come out of the woodwork so we can kill them :) > > > It could be replaced by some more robust structure (something like json or > > what ever but not XML it so verbose). > > > >> > >>> 3) Inflexibility > >>> > >>> Solution: Create a method that expands what the generators created, > >>> and order according to the order the user asked for. > >> > >> In our custom test suite we already have some considerable advances > >> here. It would be my pleasure to propose our solution for reviewing by > >> attaching two documents here or in separate e-mail. Of course only if > >> you wish so. > > > > Please show us your implementation if it match new implementation goals > > then > > it could be used. > > > > Yes, that is real problem of today implementation, I though about repairing > > this problem but it lead to more pass through cart config structure. > > It should be repaired. > > > > Fixing this problem leads to generation dictionary over multipass of > > variants > > in today implementation. It is more time expensive. > > Paolo suggest use some SAT solver for parsing variants and I have almost > > prepared > > splitting of cart config lexical parser from generator of final dictionary. > > Then could be dictionary generator replaced by something else. > > However external SAT solver => dependency on external C code wrapped to > > python. > > It must be considered. > > Yep, the external dependencies might not be where we want to be. I'm not > sure. > > Do you think saving the list from the generator then ordering the dict > can be considered as a passable workaround? As of today, the size of the > typical test list is in the order of a dozen to a few thousand tests > tops, so it shouldn't be that much of a problem saving and re-ordering. No dicts can't be saved it eats lots of memory. config.file -> parsing config -> (quite small) structure of node objects -> generator of dict -> (huge) dicts "structure of node objects" could be prepared better to allow possibility split parser from final dictionary generator. The "generator of dict" could be switchable then. > > >> > >>> 4) Generate variants from tests > >>> > >>> Solution: Well, no idea on this one yet :) > >> > >> I would generally deprecate such practice as the complexity will be > >> raised even more. In our experience and developed tests we haven't > >> encountered a need for some thing like this but I guess this is why I > >> cannot really prove a point here. > > > > I've never needed use this functionality. Is there anybody who did? > > See my answer to Plamen, where I mention Eduardo's feedback. > Oh yes, ok then. _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
