- 18 Jan, 2024 4 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 17 Jan, 2024 29 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
-
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 7 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 nexedi/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
-