locations for pvi bob etc. files.

[gilesknap]

An update from today's meeting.

Essentially:

• Build Time:
  • all module's ibek.support.yaml -> /epics/ibek-defs
  • all module's pvi.device.yaml -> /epics/pvi-defs
• Runtime
  • pvi generated bobs, index, */epics/pvi-defs/.yaml** -> /epics/opi (mounted at HTTP-PVC/blxxx-ii-ioc-nn) DESTRUCTIVE copy
  • pvi generated templates -> /tmp/startup [OR THIS COULD BE A PVC too]
  • st.cmd, ioc.subst, ioc.db -> /tmp/startup (this is a change to current)
  • NEW: extra schema for ibek.ioc.yaml allows globs of opi files to be copied to -> /epics/opis
  • BUT: these will be symlinks in the devcontainer to allow editing originals (the devcontainer mode will be a default flag to ibek runtime generate)
  • ADDENDUM. In the devconatiner you don't usually run ibek runtime generate but instead run start.sh so in fact we may need a parameter to start.sh OR perhaps just look for an env var that we know will be set, like REMOTE_CONTAINERS.
  • Soft IOCs like Pandablocks: pvi generated opis -> /epics/opis
  • @coretl will PandaBlocks ioc also need to copy the pvi yaml ???

This all means that the /epics/opis folder can be shared over HTTP as is and no rsync required

[gilesknap]

Re that long discussion on the argument to pass.

It in fact needs to be on the start.sh script so start.sh --dev would be OK. But only if we set the bob files to read only so that you get some indication that you forgot this option.

[gilesknap]

@GDYendell would you like to work together next week. To finalise this and get your PR merged - we might as well include the templates as well so that we can say ibek / pvi integration is comple.

[GDYendell]

But only if we set the bob files to read only so that you get some indication that you forgot this option.

I think this is critical whatever the API is.

would you like to work together next week

Yep!

[GDYendell]

If we are taking the bob section out of support.yaml so that it is not set in stone at container build time, does that mean the config needs to go into the ioc.yaml so that the ibek add-bob ... calls can be included in the generated start.sh?

[coretl]

I think there's 2 parts to this:

1. We need the ability for ibek add-bob... to be run either manually in start,sh, or as a section in ioc.yaml.
2. If we are using ioc.yaml we also need the ability to associate one of these bobs as the one to be linked as an index, in preference to the pvi generated one

I suspect that most people will not be using manually generated bob files at the IOC level, so maybe they will be happy with the autogenerated pvi ones and this will be a non-issue? Either way, as we don't have clear requirements, I suggest we defer this for now.

[gilesknap]

Isn't it pretty much a case of lifting the pvi:opi section from support schema and putting it in ioc schema. The code that reads the opi bits still runs at runtime anyway.

If it is easy to do then let's do it now. Then we have a custom bob mechanism that people can try if needed.

[coretl]

It's not quite the same, as the ibek support yaml structure allows us to define a bob file per definition, while if we do a straight copy of that into the ioc yaml we would have to do this per entity. This means we would have to specify the same bob file for every motor on the beamline for instance. I think we should strip it out for now, and put it back in when we have a use case.

[GDYendell]

Maybe we need some way to do additional definition config in ioc.yaml so that it doesn't have to be duplicated for every entity. I agree, let's just use the pvi bobs for now.

[gilesknap]

:+1:

[gilesknap]

So I believe this is all resolved now.

• We have a structure in place for where runtime assets and pvi device files go.
• We have the pvi entry in support.yaml which attaches pvi bob and PV prefixes etc.
• We generate bobs as part of start.sh and publish them via a PVC and 'epics-opis' service.

@GDYendell do you agree this can be closed?

[GDYendell]

I think so, although a lot of our ideas above are not what we have now. Is what we ended up doing summarised nicely somewhere?

[gilesknap]

Probably not. I'll leave this open as a 'document pvi / ibek integration'