RTEMS - Creating a File Server#

Warning

This tutorial is out of date and will be updated in December 2023.

Introduction#

RTEMS IOCs are an example of a ‘hard’ IOC. Each IOC is a physical crate that contains a number of I/O cards and a processor card.

For these types of IOC, the Kubernetes cluster runs a pod that represents the individual IOC. However, the IOC code itself runs on the processor card instead of the pod. The pod provides the following features:

Sets up the files to serve to the RTEMS OS
Provides a connection to the IOC console just like a linux IOC
Pauses, unpauses, restarts the IOC as necessary - thus the IOC is controlled by the Kubernetes cluster in the same way as a linux IOC
Provides logging of the IOC console in the same way as linux IOCs
Monitors the IOC and restarts it if it crashes - using the same mechanism as linux IOCs

At present epics-containers supports the MVVME5500 processor card running RTEMS 5. The same model as described above can be used for other ‘hard’ IOC types in future.

Create a File Server Service#

When an RTEMS 5 IOC boots the bootloader loads the IOC binary from a TFTP address, this binary is then given access to a filesystem over NFS V2, this is where the IOC startup script and other configuration is loaded.

Therefore we need a TFTP server and an NFS V2 server to serve the files to the IOC. For each EPICS domain a single service running in Kubernetes will supply a TFTP and NFS V2 server for all the IOCs in that domain.

In the tutorial Create a Beamline Repository we created a beamline repository that defines the IOC instances in the beamline bl01t. The template project that we copied contains a folder called services/nfsv2-tftp. The folder is a helm chart that will deploy a TFTP and NFS V2 server to Kubernetes.

Before deploying the service we need to configure it. Make the following changes:

Change the name value in Chart.yaml to bl01t-ioc-files
Change the loadBalancerIP value in values.yaml to a free IP address in your cluster’s Static Load Balancer range. This IP address will be used to access the TFTP and NFS V2 servers from the IOC.

Note

DLS Users The load balancer IP range on Pollux is 172.23.168.201-172.23.168.222. Please use 172.23.168.203. The test RTEMS crate is likely to already be set up to point at this address. There are a limited number of addresses available, hence we have reserved a single address for the training purposes.

Also note that bl01t is a shared resource so if there is already a bl01t-ioc-files service running then you could just use the existing service.

You can verify if the service is already running using kubectl. The command shown below will list all the services in the bl01t namespace, and the example output shows that there is already a bl01t-ioc-files service using the IP address 172.23.168.203.

$ kubectl get services -n bl01t
NAME                TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                                        AGE
bl01t-ioc-files     LoadBalancer   10.108.219.193   172.23.168.203   111:31491/UDP,2049:30944/UDP,20048:32277/UDP,69:32740/UDP                      32d

Once you have made the changes to the helm chart you can deploy it to the cluster using the following command:

cd bl01t
helm upgrade --install bl01t-ioc-files services/nfsv2-tftp -n bl01t

Now if you run the kubectl get services command again you should see the new service.

Once you have this service up and running you can leave it alone. It will serve the files to the IOCs using the IP address you configured over both TFTP and NFS V2. It uses a persistent volume to store the files and this persistent volume is shared with hard IOC pods so that they can place the files they need to serve to the IOC.

See the next tutorial for how to deploy a hard IOC pod to the cluster.