...
Please add your name to the list
- Gergely Csatari
- Beth Cohen
- Georg Kunz
- Ulrich Kleber
- Sridhar Rao
- Luc Provoost
- Karine Sevilla
- Ildiko
- Cédric Ollivier
Antitrust policies
- Linux Foundation Anti-Trust Policy
- GSMA Anti-Trust Policy Notice
- Recorded Policies:
...
Containerization of traffic generators with Xtesting - Sridhar Rao
- Initial architecture: Integration with Xtesting - Lakelse
- Discussion of traffic generators. Where do they need to be installed?
- They need to have additional tools installed either inside or outside the environment to test.
- Need to deploy the tools (Rapid and Prox), then use K8S APIs to run the tests and collect results.
- For this work the test results are pass/fail. Stdout from "rapid" is additional results.
- So where do you put the control function (Rapid) to start and stop the traffic generator (Prox),
- Currently it HAS to be inside the environment, better to move It to outside.
- One approach
- There is a need for an application to LCM the test framework pods (Rapid, Prox), collect the results and calculate the test results
- If this application is outside of the cluster and uses the Kubernetes API-s
- For this the integration between Rapid and Xtesting needs to be modified
- Presentation of the output needs to be also changed
- Maybe there are alternate approaches
- If the complete Xtesting runs within the cluster the integration will be more easy, but in that case collecting the results is ugly and difficult
- In RA2 there are no guidelines about what are the mandatory service types
- E.g.: Nodeport, Loadbalancer, External IP
- There is an RA2 issue about this: https://github.com/cntt-n/CNTT/issues/2453
- The approach for SSH connection is not defined without this
- Best candidate would be Loadbalancer, for this RA2 should add Loadbalancer as a mandatory service
- There are tests about Ingress in the Kubernetes conformance test suite
- We are not sure if KubeRef has Loadbalancer or External IP installed
- This is a pre requisite for successful testing
- Desired architecture:
- Possible workaround:
- Next steps
- Nodeport is not a nice solution, but that supported by every Kubernetes deployments
- For this the exact node and the port should be figured out
- Nodeport is disliked by several telcos
- It is good as a first iteration, let's start with this
- Desired solution would be Loabalancer, but that needs an discussion in RA2 what cold take some time
- Nodeport is not a nice solution, but that supported by every Kubernetes deployments
AoB
- None