Integrate PVI into ibek

[gilesknap]

In order to progress #110.

On 6 Oct we came up with the following:

1. Add an opi section to each definition in support YAML. Trial example here
2. Change Support YAML schema to match. (Already Done Here)[https://github.com/epics-containers/ibek/blob/53f0aa317693b90e41c70a7d4eb20fd7985f1295/src/ibek/support.py#L205-L207]3.
3. update the ibek support generate-links command to copy bobs and pvi files into the /epic/links folder. This probably requires extra arguments to specify which hand-crafted bobs should be copied. See Here
4. update ibek runtime generate to make bob files from PVI files at IOC instance launch time. See Here This function will also generate the required index.bob for the IOC - this needs to be a button for each screen instance with the PREFIX macro set accordingly.

Note that we were undecided about whether generated screens should have a PREFIX macro or should use $(P):$(R) or whatever the unique identifier is for the given support module.

Some work already started in pvi-changes branches of ibek and ioc-adaravis
Gary will do this work to get an intro to ibek.

[gilesknap]

@coretl please comment if the above looks wrong.

[gilesknap]

@coretl please could you write down what you said in the verbal response to this issue? I tried but became fuzzy on the details.

I'd like to make the point that we should support people who don't want to use ibek and maybe even bobs. Therefore the opi section should include a list of file globs for copying into the /epics/exports/opi area. This leaves indexing up to the developer - but it provides the ability to file inside the container the correct versions of the GUI files for the support modules that you have built into your IOC executable.

[coretl]

• Add opi section to support YAML with precisely one entry, the top bob or yaml file that index.bob should make a button for
• ibek support generate-links should take globs of paths to make links for in /epics/opi. These paths should always link pvi yamls, but can also link bobs and pngs for pre-generated screens. Not sure if it should be doing ibek yamls too, as they need to go in a different directory. Maybe rename to link-opi and add a link-ibek command that puts them in /epics/ibek? Or pass to the register command as an arg?
• Should it be /epics/exports/opi or /epics/opi? What else do we want to export?
• At runtime then something should make bob files from pvi files, taking an argument of the formatter, using a predictable prefix and file path. This needs to be run either manually in start.sh with a provided formatter argument, or from the ibek start.sh with formatter from the ibek ioc.
• At runtime if generating substitution file and startup script also make index.bob from the opi entries of all entities

I think if we do this we make bob files available even if you don't use ibek ioc yaml files

[gilesknap]

Today's meeting discussion decided:-

• we will populate the opi folder at runtime so that different GUI users could share a Generic IOC
• for dev time this is OK as you can run ibek runtime generte from the shell
• the folders will be called
  • /epics/opi (for pvis and bobs or other opi files
  • /epics/ibek for support yaml
• ibek support generate-links will copy ibek support yaml files as it currently does at container build time
• ibek runtime generate will:
  • copy opis (with arg for multiple globs)
  • generate bobs from pvis
  • generate an index bob
  • generate a db template for ophyd and add it to the subst (for ophyd info tags to be added to PVs)
  • generate startup and db
• there will be separate ibek functions for the various steps but generate will be a convenience function that calls them all

@coretl @GDYendell did I forget anything?

[coretl]

I think that looks right, although ibek support generate-links should link not copy ibek support, and maybe it should be called ibek support link-ibek-support-yaml?

[GDYendell]

I think this looks right.

generate a db template for ophyd and add it to the subst (for ophyd info tags to be added to PVs)

Does this mean it will be appending to a substitution file that is initially created at generic-ioc build time?

I think ibek support generate-links is fine.

[gilesknap]

I think that looks right, although ibek support generate-links should link not copy ibek support, and maybe it should be called ibek support link-ibek-support-yaml?

It truth it could be called ibek ioc link-ibek-support-yaml and get run once in the main Dockerfile - at present it looks for all support modules and copies all it finds.

[gilesknap]

I think this looks right.

generate a db template for ophyd and add it to the subst (for ophyd info tags to be added to PVs)

Does this mean it will be appending to a substitution file that is initially created at generic-ioc build time?

I think ibek support generate-links is fine.

The main subst file is created when we read the IOC instance yaml at runtime. I think we could just have the ophyd one generated at build time as as separate subst and expand >1 subst at runtime, include >1 db file. Or we could merge subst. Or we could save info for generating the ophyd parts of the one global subst (in a yaml file of course!)

[coretl]

I think that looks right, although ibek support generate-links should link not copy ibek support, and maybe it should be called ibek support link-ibek-support-yaml?

It truth it could be called ibek ioc link-ibek-support-yaml and get run once in the main Dockerfile - at present it looks for all support modules and copies all it finds.

It needs to be run once per support module so we can decide based on version number which support yaml to link, each time we add a new database template to expose to ibek we will have to change the support yaml so will have a number of versions

[coretl]

The main subst file is created when we read the IOC instance yaml at runtime. I think we could just have the ophyd one generated at build time as as separate subst and expand >1 subst at runtime, include >1 db file. Or we could merge subst. Or we could save info for generating the ophyd parts of the one global subst (in a yaml file of course!)

I think that whenever we get a xxx.pvi.device.yaml we should generate a xxx.pvi.bob and a xxx.pvi.template. This should be able to be generated whether or not we are using an ibek.ioc.yaml. Because of this it should always use that well know filename pattern, and use $(prefix) as the pv prefix.

If we use an ibek.ioc.yaml file for each instance we should insert instances of all dbs and xxx.pvi.template in the substitution file. If someone manually makes a subst file it is up to them to make the xxx.pvi.template files.

[gilesknap]

@GDYendell think we are ready to close this?