• Kirill Smelkov's avatar
    software/ors-amarisoft: Start to introduce ORS mode · f3f1cb46
    Kirill Smelkov authored
    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 nexedi/slapos!1522
    /reviewed-by TrustMe
    f3f1cb46
instance-ors.cfg 5.43 KB