- 17 Jan, 2024 26 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Whether RU is enabled or disabled is controlled via per-ru ru.txrx_active
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
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.
-
Kirill Smelkov authored
-
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
-
- 16 Jan, 2024 13 commits
-
-
Kirill Smelkov authored
After escaping strings with dumps (to avoid buildout breakage and code injection on "tricky" references, e.g. with spaces), promises started to be generated with !py! prefix in their filenames, e.g. as '!py!'\''RU1-sdr-busy.py'\''' instead of just RU1-sdr-busy.py The issue here is that our code set name = !py!'RU1-sdr-busy.py' and then monitor-promise-base from stack/monitor does output = ${directory:plugins}/${:name} which, I though, would be expanded to .../etc/plugin/RU1-sdr-busy.py but it did not deserialized the :name upon expansion. I feel like it is maybe a bug in slapos.buildout@4e13dcb9 , but I'm not sure. Anyway, workaround the problem by generating :output ourselve also via escaped way.
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
urlparse does not handle raw IPv6 address the way I though it does - extracted hostname is not the whole address, but only the first part of it: In [3]: urllib.parse.urlparse('z://2a11:9ac1:6::5') Out[3]: ParseResult(scheme='z', netloc='2a11:9ac1:6::5', path='', params='', query='', fragment='') In [4]: _.hostname Out[4]: '2a11' Tests did not noticed this because previouslt we had e.g 4321::1 in the address, and netaddr thinks 4321 is valid ipv4 address: In [6]: netaddr.IPAddress('4321') Out[6]: IPAddress('0.0.16.225') However changing IPv6 addresses to use hex letter trigger the bug with e.g. raise AddrFormatError('failed to detect a valid IP ' \ netaddr.core.AddrFormatError: failed to detect a valid IP address from '2a11' -> Fix it by avoiding urlparse and doing ip/port splitting ourselves by hand. /reported-by @lu.xu
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
when serving symlinks via raw, lab returns link content (= readlink), not content of the target.
-
Kirill Smelkov authored
-
- 15 Jan, 2024 1 commit
-
-
Kirill Smelkov authored
-