Re: [PATCH v1] dts: Testbed And Node Configuration Split

["Juraj Linkeš" <juraj.linkes@pantheon.tech>]

On 14. 6. 2024 20:27, Jeremy Spewock wrote:
> I think this is definitely a step in the right direction in terms of
> how we structure the config files. Something that I think could also
> be a cool improvement for how we handle configs is just making a
> `conf/` directory and then taking all of the configuration in each of
> the yaml files present in the directory and combining them into one
> config in the framework like we have now. That's definitely a larger
> undertaking however, this split will save space if users want to
> specify more than one host or use the same execution configuration
> between different node configurations and I think that is an
> improvement on its own.
> 

I like this suggestion. When we have multiple config files, it just 
makes sense to group them.

> On Mon, Jun 10, 2024 at 3:34 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
>>
>> This implementation splits the execution and node configuration
>> components of the conf.yaml into two separate config files. A
>> new command line argument is added, allowing the user to specify
>> both a node configuration file and an execution configuration
>> file. Be default, these config files are now named node_conf.yaml and
>> execution_conf.yaml, respectively.
>>
>> To assert these changes, the schema calls for one of these objects,
>> nodes or executions, in each file, but neither config file can have
>> both.
>>
>> To avoid excess refactoring, both config files are merged together
>> early on in the load_config process.
>>
>> Bugzilla ID: 1344
>>
>> Signed-off-by: Nicholas Pratte <npratte@iol.unh.edu>
>> ---
> <snip>
>> diff --git a/dts/testbed_conf.yaml b/dts/testbed_conf.yaml
>> new file mode 100644
>> index 0000000000..af2180eac2
>> --- /dev/null
>> +++ b/dts/testbed_conf.yaml
> 
> I don't think this file is used anywhere and it looks like another
> name for the execution_conf.yaml so we likely don't need it.
> 

We actually don't want the execution_conf.yaml file (and use 
testbed_conf.yaml), but the point stands - there are two files that are 
the same.

>> @@ -0,0 +1,26 @@
>> +# SPDX-License-Identifier: BSD-3-Clause
>> +# Copyright 2022-2023 The DPDK contributors
>> +# Copyright 2023 Arm Limited
>> +
>> +executions:
>> +  # define one execution environment
>> +  - build_targets:
>> +      - arch: x86_64
>> +        os: linux
>> +        cpu: native
>> +        # the combination of the following two makes CC="ccache gcc"
>> +        compiler: gcc
>> +        compiler_wrapper: ccache
>> +    perf: false # disable performance testing
>> +    func: true # enable functional testing
>> +    skip_smoke_tests: false # optional
>> +    test_suites: # the following test suites will be run in their entirety
>> +      - hello_world
>> +      - os_udp
>> +    # The machine running the DPDK test executable
>> +    system_under_test_node:
>> +      node_name: "SUT 1"
>> +      vdevs: # optional; if removed, vdevs won't be used in the execution
>> +        - "crypto_openssl"
>> +    # Traffic generator node to use for this execution environment
>> +    traffic_generator_node: "TG 1"
>> \ No newline at end of file
>> --
>> 2.44.0
>>