Jérome, thanks for looking into this issue.
@rafael, @jerome, thanks for feedback.
Rafael, I understand what you say and there is no urgency on my side. Just when this MultiRU story was beginning I was explicitly asked by @jp to add support for radio units and cells as shared instances. So whatever there is a way to do it with one main eNB/gNB instance and other secondary RU/Cell/Peer/PeerCell instances attached to it, the "ors-amarisoft" software release, I think, could adapt. But there should be some way.
For the reference everything works already as is when things are requested via scripts and it is only WEB UI that does not work properly. I would say the WEB UI could be adapted relatively easily, without any patching to core slapos, to support multiple shared with the same software_type because all choices are already keyed with different keys in software.cfg.json :
https://lab.nexedi.com/nexedi/slapos/-/blob/25439fae/software/ors-amarisoft/software.cfg.json#L5-49
For example eNB shared for Radio Unit is keyed as ru
, while eNB shard for Cell is keyed as cell
:
https://lab.nexedi.com/nexedi/slapos/-/blob/25439fae/software/ors-amarisoft/software.cfg.json#L14
https://lab.nexedi.com/nexedi/slapos/-/blob/25439fae/software/ors-amarisoft/software.cfg.json#L23
I think the UI could use those keys to organize distinct choices and distinct forms and switch between them correctly just fine.
And on SR side there is no problem that all those variants come with the same software_type because the code checks for presence of particular keys in the passed parameters and different variants have different const parameters that allow the code to see which variant it is. For example RU comes with ru_type
present, while Cell comes with cell_type
present.
And regarding template
I understand that it might be posing a problem to current implementation. That's exactly why I posted https://github.com/json-editor/json-editor/pull/1446 some time ago so that we could replace those template
with just const
. In my view it should help, but maybe I'm missing something. In any way if the UI is adapted to organize different forms for different keys as explained above, there should not be a problem as all cases should be handled correctly - be it template or just const used for the type parameter.
I understand the word "shared" is not very descriptive and that what we used previously instead has more meaning, and I also understand that in the new design it might be just regular instances without being shared or slave that are linked to each other. It would be good to have such flexibility; thanks for sharing about that.
Kirill
Kirill Smelkov (eb22e363) at 25 Mar 19:13
software/ors-amarisoft: Workaround SlapOS Master inability to handle shared instances of multiple types
While upcoming SlapOS Master should be able to handle multiple types of shared instances attached to the same main instance, current SlapOS Master UI does not handle it well, and explicitly rejected to do so with dae3ad01 , which turned json-schemas check failing for ors-amarisoft as
FAIL: test_ors-amarisoft_software_cfg_json (slapos.test.test_json_schema.TestJSONSchemaValidation)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../slapos/slapos/test/test_json_schema.py", line 81, in run
assert _software_type_tuple not in _viewed_software_type, \
AssertionError: Duplicated software release on enb, shared: True
-> Work it around by adjusting software.cfg.json to use only one type of shared instance for each main instance, and inside schema of that type dispatch to all needed subtypes with oneOf.
This patch should be reverted when/if SlapOS Master starts to handle shared instances of multiple types well.
/cc @tomo, @jhuge, @lu.xu, @xavier_thompson, @Daetalus, @romain, @rafael, @jerome
Kirill Smelkov (aecb7f3f) at 25 Mar 19:12
software/ors-amarisoft: Workaround SlapOS Master inability to handl...
Kirill Smelkov (eb22e363) at 25 Mar 18:02
Kirill Smelkov (eb22e363) at 25 Mar 18:02
software/ors-amarisoft: optional shared_key for remote fluent-bit
... and 39 more commits
Lu, thanks for heads up.
Hello, @tomo.
As Jérome explained (thanks, @jerome) those eggs are indeed added into working set so that importing them in jinja2 templates works. For slapos.recipe.template:jinja2 netaddr
is indeed already there on sys.path because netaddr is dependency of slapos.cookbook, but for eggs that are not listed in those dependencies, importing them will fail if we do not add them to the working set ourselves. Please try to comment e.g. activate('xlte')
to see such failure. The code of [activate-eggs]
has corresponding comments explaining that it is doing "activation of eggs and modules used in jinja2 templates". I thought that is enough, but if the comment is not clear we could try to improve it.
Xavier, thanks also for sharing your thoughts about how to do the activation more automatically instead of manually at low level. It would be good if there is straightforward way to do without delving into pkg_resources details. It also feels we are picking virtualenv-style semantics in steps more and more, so maybe, at some point, it would be better to just switch to using full virtualenv without needing to do any kind of manual activation and other workarounds at all.
Kirill
Hello Levin.
Thanks for feedback and for providing the numbers. It is good to see the difference in between ZBlk0 and ZBlk1 on the field. On my side I started the review but it did not went smoothly. Last time I ran out of time and will try to do the second iteration somewhere in the future. For you information: when converting from ZBlk1 to ZBlk0 we are going on an edge very close to corrupting data. The data is not really corrupted, but I think it is mostly so due to luck, so at least this deserves an explaining warning comment in corresponding place. There is a huge difference in doing something correctly due to luck or consciously. This problem is already resolved on my side, but there are other problems. I will try to resolve them next time I have time to work on this topic.
Kirill
Hello, @jerome.
Thanks for posting this! It is good to see progress on this topic. I will be mostly away during the next three weeks, but i quickly looked and the changes seems to be good after brief inspection and I trust you to make reasonable judgement on the details. So please go ahead and merge this. And it is especially it is good to see the progress on slapos.core integration!
I had a few remarks noticed randomly:
maybe when testing content of subpart of a dict something like my assertMatch could be useful:
https://lab.nexedi.com/nexedi/slapos/-/blob/ccbe9a26/software/ors-amarisoft/test/test.py#L802-882
https://lab.nexedi.com/nexedi/slapos/-/blob/ccbe9a26/software/ors-amarisoft/test/test.py#L398-405
not sure why tests started to use str(tmpdir)
instead of tmpdir
. A comment or separate patch for this change should likely make this clear.
Thanks, once again, for you contribution!
Kirill
Kirill Smelkov (acd01805) at 18 Feb 06:10
Kirill Smelkov (7989e6ce) at 18 Feb 06:09
I've merged my work as ed138c6e and c16a8274...acd01805. Good to go for the new system.
EDIT See !1508 (comment 199617) for updated description.
original description:
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:
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
I've merged the patch as 7989e6ce.
Kirill Smelkov (7989e6ce) at 18 Feb 06:01
software/ors-amarisoft: Do not recreate slaptapX-* on every idempot...
... and 100 more commits
Hello up there. This merge-request brings in major update to ors-amarisoft software release: first eNB is significantly restructured to prepare base for further changes, and then we add support for working with multiple radio units and multiple cells with all LTE/NR and FDD/TDD simultaneously. All kinds of Carrier Aggregation - LTE+LTE, NR+NR and LTE+NR are now supported. All kinds of Handover - Intra-ENB, Inter-ENB with LTE→NR and NR→LTE are now supported as well. UE simulator is also updated to support multiple radio units, cells and UEs. In the new system configuration of RU, CELL, PEERCELL, PEER and UE objects are done via shared instances attached to the main eNB or UEsim instance.
Most of the parameters become runtime settings instead of being static choice of particular software template. There is no longer multiple rendered softwares - all that remain is
software.cfg
for generic software, andsoftware-ors.cfg
for ORS.Switching to configuring things at runtime became possible because SlapOS Master
recently switched to new JSON-editor with support for oneOf
, arrays and
conditionals - bits that make it possible to configure settings in the WEB UI
with multiple choices for e.g. RF mode, cell or radio unit type.
For ORS full backward compatibility is preserved via special proxy which
translates ORS input schema to configuration objects of the new generic eNB.
Since most our current ORS deployments are TDD, software-ors-tdd.cfg
link to
software-ors.cfg
is also provided to preserve backward compatibility at
software-release URL level for those instances.
eNB and gNB are merged along the way. Unittests are improved. JSON schemas
become primary source for defaults(*). Unnecessary parameters are removed and
are now computed automatically. For example it is no longer needed to
explicitly specify SSB NR-ARFCN for peer NR cell, or txa0cc00_center_frequency
for Lopcomm RU. tx_gain
and rx_gain
become generic parameters that
semantically apply uniformly to all Radio Units.
A protection against buildout code injection via specially-crafted references
of shared instances is installed. The problem was noticed because instantiation
was failing with spaces in the references - a condition that is present by
default on the testnodes. Solving the problem generally via custom "buildout
encoding" was not hard and probably the solution might be useful not only for
ors-amarisoft software release. Please see the patch "Protect from buildout code injection"
for details.
There are more minor enhancements and bug fixes in there.
Please see individual patches for details.
Kirill
/cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
(*) this goes in line with similar design choice to make JSON schemas primary source of defaults in Rapid-CDN: !1380 .