1. 19 Jan, 2024 1 commit
  2. 18 Jan, 2024 4 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Push amarisoft-stats.jinja2.py and amarisoft-rf-info.jinja2.py into ru/ · 7715bc9b
      Kirill Smelkov authored
      Because
      
      1) those services are needed and used only by ru/ promises like check_cpri_lock
         and check_rx_saturated.
      2) in general we will need to initialize and setup radio units not only in eNB -
         for example UEsim will use the same code library to initialize radio units.
         Thus the proper place to keep everything required for RU to be operational have to
         be located inside ru/ and activated by that radio-units library.
      
      Push corresponding code from instance-enb to ru/ and do only minor adjustments
      to instance-gnb trying not to break it, since gnb does not currently use rulib,
      and because in the future gnb will be replaced by enb which will be serving
      both lte and nr cells in the same service.
      
      /cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
      7715bc9b
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Push SSH server code into ru/lopcomm/ · 316aaad9
      Kirill Smelkov authored
      Because:
      
      - ssh server is needed for and used by ru/lopcomm/ only
      - in general we will need to initialize and setup radio units not only in eNB -
        for example UEsim will use the same code library to initialize radio units.
        Thus the proper place to keep everything required for RU to be operational have to
        be located inside ru/ and activated by that radio-units library.
      
      /cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
      316aaad9
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Do not give RU more than /64 · ac8e87eb
      Kirill Smelkov authored
      Dnsmasq insists on dhcp-range's prefixlen to be at most 64, which
      triggers the following error if original slaptap is wider than that:
      
          dnsmasq: prefix length must be at least 64 at line 5 of /srv/slapgrid/slappart6/etc/dnsmasq.cfg
      
      -> Fix it by capping provided range to /64
      
      /reported-by @lu.xu
      /cc @jhuge, @tomo, @xavier_thompson, @Daetalus
      ac8e87eb
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Do not recreate slaptapX-* on every idempotent `slapos node instance` run · 243f28de
      Kirill Smelkov authored
      To run tapsplit we use plone.recipe.command with both command and
      update-command set to `tapsplit ...`. But tapsplit, when run, fully
      recreates and reinitializes subtap interfaces, which leads to
      interfering with running enb because subtap interfaces, that enb
      started to use, are removed. This is not desirable behaviour.
      
      What we need:
      
      1) create subtap interfaces only once and keep them stable
      2) until configuration changes which should lead to
         * subtaps recreated, and
         * enb restarted
      
      Carefully reading plone.recipe.command documentation shows:
      
        command
          Command to run when the buildout part is installed.
      
        update-command
          Command to run when the buildout part is updated. This happens when
          buildout is run BUT THE CONFIGURATION FOR THIS BUILDOUT PART HAS NOT
          CHANGED.
      
        (emphasis mine)
      
      So the fix looks to be to make update-command noop - this fulfills
      requirement "1". For "2" - I've verified that when configuration
      changes, e.g. number of RU changes, buildout reinstalls [vtap] section
      from scratch, and it also should restart enb, because generated enb.cfg
      changes.
      
      So the fix is fully correct because it satifies all needed requirements.
      
      Amends 49ce8ef5 (software/ors-amarisoft: Provide dedicated TAP interface for each Radio Unit)
      /cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
      243f28de
  3. 13 Jan, 2024 1 commit
  4. 12 Jan, 2024 1 commit
  5. 11 Jan, 2024 3 commits
  6. 05 Jan, 2024 1 commit
    • Kirill Smelkov's avatar
      format-json, test: Don't force ASCII · cd75648d
      Kirill Smelkov authored
      Currently, due to ensure_ascii=True default of json.dumps, we are
      insisting on our JSON schemas to be ascii-only and all other characters
      to be represented by \uxxxx escapes. So far this was not problematic as
      all our schemas contains only ASCII characters, but upcoming
      ors-amarisoft changes want to use e.g. "→" symbol:
      
          https://lab.nexedi.com/kirr/slapos/blob/b51f5523/software/ors-amarisoft/software.cfg.json#L15
      
      which currently results in failure of json-schema test:
      
          FAIL: test_ors-amarisoft_software_cfg_json_format (slapos.test.test_json_schema.TestJSONSchemaValidation)
          ...
      
          First differing element 14:
          '      "title": "\\u2192  eNB/gNB | Radio Unit",'
          '      "title": "→  eNB/gNB | Radio Unit",'
      
      And in general, in 2023 I think there is no reason to insist on our schemas to
      be ASCII-only: say if one wants to describe something about "α" parameter. It
      would be good to use that α character directly and seeing it in the editor,
      instead of using escapes all the time.
      
      As indicated by below stackoverflow answer "JSON spec requires UTF-8 support by
      decoders": https://stackoverflow.com/a/594881/9456786 , and indeed checking
      JSON specification also confirms that by default JSON decoders shall use UTF-8:
      
          https://datatracker.ietf.org/doc/html/rfc7159#section-8.1
      
      This way, I think, we can switch to UTF-8 safely.
      
      /reviewed-by @jerome, @lu.xu
      /reviewed-on nexedi/slapos!1498
      cd75648d
  7. 04 Jan, 2024 1 commit
  8. 02 Jan, 2024 3 commits
  9. 29 Dec, 2023 1 commit
  10. 28 Dec, 2023 3 commits
  11. 25 Dec, 2023 8 commits
  12. 20 Dec, 2023 1 commit
    • Titouan Soulard's avatar
      software/rapid-cdn: avoid RegExp to validate hostnames · 11336190
      Titouan Soulard authored
      Using RegExp to validate hostnames is a bad practice, and has a lot of reasons to be wrong.
      On top of that, the JSON Schema specification allows, since draft 7, to validate hostnames
      against an IDN hostname, by using the `idn-hostname` format.
      
      With these changes, IDN are now supported (.рф and .中國 for instance), and long TLD
      should not be a problem anymore.
      11336190
  13. 19 Dec, 2023 1 commit
  14. 18 Dec, 2023 2 commits
  15. 15 Dec, 2023 1 commit
  16. 14 Dec, 2023 6 commits
  17. 13 Dec, 2023 2 commits