osmo-gsm-tester[master]: config: Fix combination of lists

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Pau Espin Pedrol gerrit-no-reply at lists.osmocom.org
Fri Sep 8 17:58:03 UTC 2017


Patch Set 2:

Some more thoughts after spending some time adding some units tests and looking at some examples.

1) We can have 2 different uses for scenarios, and we need to agree on which we want:
- A: scenario is just a filter for a given type of object. It doesn't apply for each object in particular as in a list, but just a list of attributes to require for a given type of object. That means for instance "times" attr makes no sense here, and of course in the scenarios file we only specify 1 entry for each object type. 
Example: I set in scenario "bts: attrX=bla", then I ask for 2 BTS in suite.conf, I will end up after combine() with both BTS having attrX set to bla (and if any of those has an attrX set in suite.conf to something else, then it will fail).

- B: Scenario is a real object-to-object specific match. That means, if you have a suite.conf with 2 BTS, then you need to pass a scenario which is written in a way to explicitly set attribute for 2 BTS.
Example: In scenario file I set "bts: [{attrxX=bla}, {attrX=bla}]", then in suite.conf I also specify 2 BTS. If I use a different number of object in any of those files, then it will fail.

In case we go for "A", then we need to modify code calling config.py:combine() in suite.py:combined(), to basically apply the scenario part specific for a type of object to each of the objects in suite.conf. I think though that it makes sense to use "A" as it makes scenarios reusable, and there's no point in making them that tight to a suite.conf.


2) In any of the cases, in case we call combine() for a list of complex objects, we match objects one-to-one by index. If size of arrays mismatch, we can then understand it as if only the first len(list) are defined, and treat missing indexes as empty dictionaries/lists. This is similar as methods with default parameters. This way, If I want to define the following scenario, both should match,:

suite.conf = { 'bts': [ { 'times': '1', 'label': 'foo', 'trx': [{'nominal power': '10'}, {'nominal power': '12'}] }, { 'times': '2', 'trx': [] }] }
scenario = { 'bts': [{'type': 'osmo-bts-trx', 'trx': [{'nominal power': '10'}, {'nominal power': '12'}]}] }
config.combine(suite.conf, scenario)

after combine, "suite.conf" should be, for each case above:

- A:
{ 'bts': [ { 'times': '1', 'label': 'foo', 'trx': [{'nominal power': '10'}, {'nominal power': '12'}] }, { 'times': '2', 'type': 'osmo-bts-trx', 'trx': [{'nominal power': '10'}, {'nominal power': '12'}] }] }

-B:
{ 'bts': [ { 'times': '1', 'label': 'foo', 'trx': [{'nominal power': '10'}, {'nominal power': '12'}] }, { 'times': '2' }] }

The difference is mainly than in A, the attributes are copied to both BTS dictionaries, while in B it's only applied to the first one because we do a 1-to-1 match and we don't apply to all objects. That's why I'd personally go for A as usually that's what we'd like.


Important point in any case, summary:
- In an array of dictionaries in the general case (leave the object type case), we combine(dest[i], src[i]), where "i" is the same index.
- In an array of dictionaries, while combining them, if dest[i] or src[i] is None (because len(dest)!=len(src)), then we use empty dict instead of accessing out of bounds.

-- 
To view, visit https://gerrit.osmocom.org/3722
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ib7a38f10eb9de338a77bf1fa3afceb9df1532015
Gerrit-PatchSet: 2
Gerrit-Project: osmo-gsm-tester
Gerrit-Branch: master
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-HasComments: No



More information about the gerrit-log mailing list