Details
-
Enabler
-
Must have
-
Data Processing
-
-
-
Inter Program
-
5
-
5
-
0
-
REL-315 SKA-LOW v23.1-rc1
-
Team_YANDA
-
Sprint 5
-
-
-
-
18.2
-
Stories Completed, Integrated, Solution Intent Updated, BDD Testing Passes (no errors), Outcomes Reviewed, NFRS met, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO
-
-
LOW_SUT1 YANDA
-
SOL - G1
Description
During SP-2528 it was demonstrated that a pod running within a k8s cluster could be configured in such a way that the P4 switch could send ARP requests for its MAC address and the pod would respond successfully. This in turn configures the switch to know which port to use to forward the SPEAD packets coming from CBF into the corresponding SDP receiver node. However, during that exercise no actual SPEAD data was exchanged. Moreover, the pod used for the experiments wasn't the receiver pod, but a custom one that had all the metadata needed for the experiment to succeed. While a useful and big advance in the right direction, there is still work left to be done to ensure visibility data can be exchanged between CBF and SDP.
This feature should ensure SPEAD data can be exchanged on the PSI environments. Given the previous steps, the following items need to be clarified or worked on:
- Firstly, this experiment was performed on the LOW PSI. Is it expected that a similar setup will be available on the MID PSI, and therefore the same solutions apply to both environments?
- The solution used to have a k8s pod respond to ARP requests was to configure it with a CNI plug-in and enable it to use the host interface directly. To this effect, the pod specification needs to be told the interface to use (its PCI bus ID) and the IP to set on that interface.
- Does this works/scales if we use multiple ports in the same pod? and multiple pods in the same node? and multiple nodes?
- How does usage of this plug-in affect the Service definitions laid on top pods? Are Service definitions required in the first place?
- The receive chart needs modifications to receive this configuration
- If IPs and PCI bus IDs need to be passed down the system, who's responsibility is that? The easiest solution is to pass down these values via PB parameters, such that the vis-receive script can both put them in the receive chart, and use them to re-calculate the receive addresses that are communicated to CSP, inserting the IPs from the PB in place of the k8s hostnames
- If the receive chart still needs to define externally-visible services, the chart needs further modifications to setup NodePort services for each of the ports it will listed data on.
- Data exchange should happen using Jumbo frames, we need to investigate if/how k8s supports this.
Once those items are tackled, we should be able to test an integrated system on the LOW PSI with SPEAD visibility data travelling into a receiver pod started via the usual SDP Tango interfaces.
All of the above applies to multiple nodes rather than a single receive pod.
For some further details on the setup used during SP-2528 please visit https://confluence.skatelescope.org/display/SWSI/PSI+Low+Deployment+and+Operations#PSILowDeploymentandOperations-Low-levelaccesstonetworkinterfacesandadditionalinterfaces