Draft: Dynamically plug values for facility and os

[akim-ruslanov]

Link the Issue(s) this Pull Request is related to. Current version uses DEFAULT_FACILITY value for every machine. Hence, in order to use a different value based on a machine, people have to edit and plug new logic into the code base. Same goes for SP_OS.

Summarize your change. It is now possible to define OVERRIDE_FACILITY_MODULE and OVERRIDE_FACILITY_FUNC which will represent a module and a function that define FACILITY value. The same can be done for SP_OS. The module will be imported dynamically within rqconstants.py. Unit tests were created within rqconstants_tests.py. This change should allow for a better flexibility when using values that can require different logic based on studios.

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: akim-ruslanov / name: Akim Ruslanov (176748473e48c7848127a42113361f330ce2ac7b)

[akim-ruslanov]

We should add a commented example of the new entries to the config file so users can know this feature exists without having to navigate the code. This comment should mention a suggestion of where to place files with the add-on modules.

Which config file should we use for that? Currently, rqd looks for config file either outside of project directory, or look for one dynamically based on the arguments. Should I create a sample config file instead then?

[DiegoTavares]

We should add a commented example of the new entries to the config file so users can know this feature exists without having to navigate the code. This comment should mention a suggestion of where to place files with the add-on modules.

Which config file should we use for that? Currently, rqd looks for config file either outside of project directory, or look for one dynamically based on the arguments. Should I create a sample config file instead then?

True, this version doesn't have a config file as an example, we could add one with the basic configs to rqd/deploy

[DiegoTavares]

From the last TSC meeting:

@bcipriano mentioned his work on restructuring the config will try to contemplate this feature in more structured way.