ibek equivalent of GDA Plugins

[gilesknap]

This is an idea to create an ioc.yaml that will be reused more than once by multiple IOCs.

To implement this the shared ioc.yaml will be placed in a submodule or shared folder in the services repository, it will be symlinked into every services/xxx/config folder that needs it.

The yaml will be parameterized by using Jinja in exactly the same way as it currently is. The difference will be that each config folder will be able to inject additional parameters into the jinja context via and env.yaml file in the config folder.

e.g.

shared ioc.yaml will look like:-

# yaml-language-server: $schema=https://github.com/epics-containers/ioc-adaravis/releases/download/2024.11.1/ibek.ioc.schema.json

ioc_name: "{{ _global.get_env('IOC_NAME') }}"

description: auto-generated by https://github.com/epics-containers/builder2ibek

entities:
  - type: devIocStats.iocAdminSoft
    IOC: "{{ ioc_name | upper }}"

  - type: ADAravis.aravisCamera
    CLASS: {{ env.cameraClass }}
    ID: {{ env.cameraID }}
    P: {{ env.prefix }}
    PORT: DET.CAM
    R: ":DET:"

  - type: ADAravis.aravisSettings
    camera: DET.CAM

  - type: ADCore.NDPvaPlugin
    NDARRAY_PORT: DET.CAM
    P: BL47P-EA-DET-01
    PORT: DET.PVA
    R: ":TX:"
    PVNAME: {{ env.prefix }}:TX:PVA

env.yaml will look like:-

cameraClass: AutoADGenICam
cameraID: 192.168.250.3
prefix: BL47P-EA-DET-01

The changes to ibek will be minimal. It will initially look for env.yaml and if found will apply the list of variables into the jinja context before parsing the ioc.yaml file exactly as before

[gilesknap]

UPDATE:
@marcelldls suggests

# yaml-language-server: $schema=https://github.com/epics-containers/ioc-adaravis/releases/download/2024.11.1/ibek.ioc.schema.json

ioc_name: "{{ _global.get_env('IOC_NAME') }}"

description: auto-generated by https://github.com/epics-containers/builder2ibek

env: env.yaml

entities:
...

To explicitly declare the environment file

[gilesknap]

Update - lets change the way we do this.

Requirements:

• Take any Areadetector and add a fixed set of plugins

Implementation:

• have a soft support module with its own ibek.support.yaml file.
• At init time clone the support module into a PVC
• add the ibek.support.yaml into entity models
• thus allowing instantiation of e.g. gdaPlugins entity with ioc.yaml
• for schema support - have an extras.yaml per soft support module with its schema taken from the artifcats published by each soft support.

This would also work for e.g. additional DB templates that use device INP fields and hopefully cover most of what beamline support modules do.

if you have gensub then you would need a new generic IOC for the beamine including all of its gensub --> asub records but this can be standalone because all inputs and outputs are CA links.

[gilesknap]

extras.yaml:

• will include a reference to the git repo to clone
• if we have multiple extras.yaml, each of these then they can have an individual schema reference at the top just like ioc.yaml does and no magic required.
• but also we could make a devcontainer for services repos that has some intelligence regarding interpretation of extras. (but I prefer the above fixed schema - even if we do consider a services devcontainer)