epics-containers / bl38p Goto Github PK

Switching to epics-containers is a great opportunity to apply some rules to naming conventions for IOCs (maybe).

I propose that we mandate 1 IOC per device as far as possible.

Names are lower case versions of previous ioc naming styles with the same domains (helm only allows lowercase/numeric and '-'). But we drop the 'ioc' in favour of a device description. e.g.

• bl38p-mo-panda-01

When doing j20 I settled on the following for diagnostic cameras:

• bl20j-di-phdgn-02

https://gitlab.diamond.ac.uk/controls/containers/beamline/bl20j
But I'm conflicted about that. They are actually dcams so perhaps bl20j-di-dcam-02 would do.
However, I chose phgdn because the PV's look like BL20J-DI-PHDGN-02:CAM: ...

This leads me to a problem with trying to set naming conventions.

• I do not want to change any PV names because its too much work and too likely to break things
• I would like the ioc name to have some relation to the PV prefixes used by the device
• I would also like the ioc name to have some relation to what the device is
• (I'd also like it if dcam-01 was on diagnostic 01 ! but I see even modern beamlines like p38 have dcam-02 on a different phdgn number so might as well give up on that)

I can't have all of the above.

@coretl @GDYendell any thoughts on this welcome.

• first the CI only loads each IOC with minimal config to verify it loads
• second there is no need for CI to complete before a release is made because ec ioc deploy gets assets direct from the tagged repo.

For the first my excuse is 'one day we will have a Tickit sim for all beamline devices and the CI will system test each IOC Instance'

For the second we could put the beamline chart and ioc folders into release assets and have ec ioc deploy pull them from there. Then you would have to wait for build success before you could deploy a versioned IOC.

BUT that seems a little masochistic to me - I kinda like the speed of versioned IOC deploy and the REAL test always comes on the beamline anyway.

@coretl any thoughts on this?

There are two naming conventions e.g (bl01j and bl01-1) which needs to be highlighted in the readme. EC_K8S_NAMESPACE env variable uses b01-1

An equivalent to the command `curl -o ~/.local/bin/bl38p https://raw.githubusercontent.com/epics-containers/bl38p/main/environment.sh?token=$(date +%s)' for the DLS gitlab repos should be advised

At present environment.sh installs itself into ~/.local/bin/bl38p and this works fine.

However, there is no automatic update if the original enviroment.sh is changed - it would be pretty useful to have this facility (but it would come at a slight startup cost probably)

At present bl38p and other domain repos have a great deal of shared code in their helm charts.

This has been convenient for dev but now it's time to factor these out into a helm chart repository. I have started this work here https://github.com/epics-containers/ec-helm-charts/actions/runs/6609481198

I need to work out what the best way to do this is for beamline-chart

• use global values
• use a library chart
• something else

Goals are minimum boilerplate in the blxxp and least complicated values.yaml in ioc instance (remembering that docker local deploys read this file too)

The IOC in this beamline repo bl45p-ea-ioc-03 runs as p38detector so that means if you exec a shell in it you get full control of all visit data.

Is this an issue and should we control it in some fashion?

@coretl I believe you discussed this with the cloud team?