Hi Holger, No timeline since I could workaround that myself so far by adding new IP addresses manually. I tend to implement this kind of new features only once I find I am really blocked or constrained by previous system when trying to add new kind of tests (or more complex ones). TBH I don't like the idea of making the suite/scenario yml file structure a lot more complex, I think current status is quite complex and makes it already difficult to gasp how to put everything together. The kind of stuff that you intend to do here can already be done far more easily by using (or extending) the python test API. That's mostly what the test does anyway: Setting up a specific topology with a pre-allocated sub-set of objects, and then do some actions on that. If you require several similar tests but with different number of objects, you can abstract that by using the "lib" feature of a suite. See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py Yes, that's why in osmo-gsm-tester initial work around this topic expects an arfcn to be actually a dictionary with ARFCN+BAND iirc. This kind of feature is similar to what scenarios provide already. The issue is still though that in order to sanely combine and override yml cfg files (lists, tuples, dictionaries, etc.) we require some restrictions in order to make it "sane" and usable for most cases. For instance right now we handle lists of "non-complex" attributes (integers, strings, etc.) as sets when combining them, but we expect lists of dictionaries to be the same size when merging them to have meaningful result (so order of items in list is important when combining or overwriting them). Lists of objects are expanded before merging suites and scenarios, so the "times" attribute is removed and item put in place in the list before combine() and override() operations are done. You may want to look at git history to understand reasons behind current system. Maybe one could use scenario modifiers to change the amount of objects from the suite.conf, that's something to explore, but I'd need to invest some time testing and reading the code too. IIRC summary is that regular suite.conf + scenarios are merged using combine(), while scenario modifiers are merged using override(). Something like [suite.conf] bts: - times: 1 [mod-num-bts.cfg] modifiers: bts: - times: 2 I think to that in order to override() you also need same list size, due to sanity checks. We could perhaps add a new "section" in scenarios which overpasses these checks, let's call it "appends" or whatever, which let's you add new requires resources to the suite. These are my 5cents, not an ultimate answer but just some advises and ideas. Regards, Pau -- - Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Hey Pau! Please take your time to respond to this. I understand that this will stall for some time now. When looking at the p4[1][2] examples I noticed they are in a similar situation. E.g. when building a network of 100 switches, it doesn't say how they are connected (I would make it one big loop). I think we are in a similar situation and have a need to define topology (without having to rewrite the test). In the interim I will make sure we can execute our single test properly. holger [1] A language to program network flow/switches. [2] https://github.com/p4lang/tutorials/blob/dc08948a344c6ff26af47d2a2447800cab…