software/ors-amarisoft: Start to introduce ORS mode
In MultiRU we are going to have generic software with flexible configuration
and many features + ORS software, which wraps the generic part, adds ORS
specific features, and translates simple ORS schema to generic ones.
Let's first move ORS-specific bits to dedicated place as a preparatory step for that:
- add software-ors.cfg . In the future software-ors.cfg will be the entry point
for ORS mode, but for now it is only a place from where software-ors-* extend from.
- add instance-ors.cfg . We move ORS-specific code from instance.cfg here and
set it to use instance-ors-enb.jinja2.cfg when instantiating enb/gnb.
- add instance-ors-enb.jinja2.cfg . This pulls ORS-specific code from
instance-enb.jinja2.cfg + instance-gnb.jinja2.cfg and wraps them with ORS
context built by instance-ors.cfg
- in the templates the way to see whether it is ORS or not, and if yes, to access
ORS parameters is changed: now it is always via checking `ors` object, which
can be either False for non-ORS mode, or dict for ORS mode, and if it is dict
the keys inside that dict are ORS specific properties, e.g. ors['one-watt'].
This adjustment is handy to organize ORS mode extension from generic with
generic setting `json ors false` in the context, and ORS mode undoing that and
setting ORS context properly. I think the code also reads more clear this way, i.e. with
{%- if one_watt == "True" %}
changed to
{%- if ors['one-watt'] %}
because in the second variant it is clear that one-watt is a property of ORS.
The rendered configs for enb.cfg and gnb.cfg stay unchanged.
/cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
/proposed-for-review-on !1522
/reviewed-by TrustMe
Showing