You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the ran simulator is exposed through a single service, and when the sd-ran chart is installed with a topology to populate, the ran-simulator itself adds per-device ports to the ran-simulator service from inside it’s pod. But the management of Kubernetes API objects is the responsibility of Helm charts and k8s controllers. For the ran-simulator to modify Kubernetes objects from within the service violates that principle. The current implementation within the ran-simulator code also suffers from some race conditions that can prevent devices from being properly exposed.
The creation of services can and should be done in the Helm chart. The chart simply needs to parse the configured file and generate services for each device. This will ensure race conditions are handled by Kubernetes so the ports are always properly exposed.
As for the services themselves, as I mentioned the simulator creates a single service and adds ports to it. But there’s no reason we can’t create a separate service per device with the appropriate port. That could simplify debugging inside Kubernetes as a single port named service would clarify the target device of network traffic to that service.
Ultimately, the management of simulated devices is a good use case for a custom Kubernetes controller/operator where the controller can simulate changes/failures within the broader environment as well, but that’s an effort that would be better to take on once the simulator is more complete.
The text was updated successfully, but these errors were encountered:
Currently, the ran simulator is exposed through a single service, and when the sd-ran chart is installed with a topology to populate, the ran-simulator itself adds per-device ports to the ran-simulator service from inside it’s pod. But the management of Kubernetes API objects is the responsibility of Helm charts and k8s controllers. For the ran-simulator to modify Kubernetes objects from within the service violates that principle. The current implementation within the ran-simulator code also suffers from some race conditions that can prevent devices from being properly exposed.
The creation of services can and should be done in the Helm chart. The chart simply needs to parse the configured file and generate services for each device. This will ensure race conditions are handled by Kubernetes so the ports are always properly exposed.
As for the services themselves, as I mentioned the simulator creates a single service and adds ports to it. But there’s no reason we can’t create a separate service per device with the appropriate port. That could simplify debugging inside Kubernetes as a single port named service would clarify the target device of network traffic to that service.
Ultimately, the management of simulated devices is a good use case for a custom Kubernetes controller/operator where the controller can simulate changes/failures within the broader environment as well, but that’s an effort that would be better to take on once the simulator is more complete.
The text was updated successfully, but these errors were encountered: