Local HTTP server

[gilesknap]

For the developer experience to work nicely when fixing PVI screen generation we need to locally support HTTP serving of bob files.

Otherwise you are left with a full container build / deploy cycle to try changes.

This will also serve as part of the Kubernetes Free approach to deploying containers.

[gilesknap]

@coretl suggests just using local filesystems. This would work for dev time. This of course makes it possible to be able to edit the files which would be an important part of dev.

However we have an issue once we start symlinking files. They would be useless outside the container unless:-

• only allow editing of support module's opis if it is in ibek support develop mode.
• make sure that the symlinks targets are therefore available outside the container (support modules under development will be in the host filesystem).

This does leave the issue of wanting the paths to be the same inside and outside the container. More thought required.

[coretl]

I think we could solve this by:

• Mounting any repo we want inside the container using its host path
• Providing some ibek develop command to edit the RELEASE.local to point to it
• Have the ibek thing-that-links-opis copy from modules in /epics and link from things anywhere else
• Have /epics/opis be a volume if we need it to be visible outside

This way the opi command can get info about what is read-only and what is read-write from its location

[gilesknap]

This all sounds good except ...

• Mounting any repo we want inside the container using its host path

I'm not happy with random locations inside the container being mounted to match the host path. This could cause clashes that overwrite legitimate things in the container for example and it seems untidy.

If we instead always use /repos can we not contrive some symlinking to make it still work?

[coretl]

The only issue with this is that if /repos and /epics/opi are both mounts to arbitrary locations in the filesystem then there is no way to make a link in /epics/opi to an opi in a support module in /repos, either relative or absolute. To fix this we can do one of 2 things:

• If the path inside is the same as outside we can use absolute links that will work outside or inside
• If <outside-mount-for-opi>/../../repos/<support_module> gets you to the support module outside, then we can use relative links. This would mean a directory structure like:

  - repos/
  - <support_module>
  - ioc-adaravis/
  - opi/
    - lots of links to ../../repos/<support_module>/...

  which seems a bit restrictive...

[gilesknap]

I agree. I want to have think about this - but not sure there is an elegant solution.

[gilesknap]

@coretl I've remembered the most important reason we should stick with /repos See https://github.com/epics-containers/ibek/issues/142#issuecomment-1819261178

[coretl]

Ok, so if we stick with /workspace (as we decided on in #142), then here are the options I can think of:

• We put phoebus in the container, and use that for development. Soft links work fine no matter whether they are absolute or relative
• We mount the parent of ioc-xxx as /workspace and put opis there at develop time. That would give us the following host structure:

  - arbitrary_path/
  - ioc-adaravis/
  - opis/
  - ADCore/
  - ADAravis/

  The second requires more thought to allow @GDYendell 's use-case of using the same dev ADCore in ioc-adaravis and ioc-adpilatus...

[GDYendell]

Wouldn't ioc-adaravis and ioc-pilatus just both use /workspace/ADCore inside the container?

[coretl]

so you would have?

- arbitrary_path/
  - ioc-adaravis/
  - ioc-adpilatus/
  - opis/
  - ADCore/
  - ADAravis/
  - ADPilatus/

Shared opi directory between them?

[coretl]

Or stick the opis directory inside ioc-xxx?

[GDYendell]

I think it doesn't matter where the ioc-xxx goes on the host, because it is the primary mount of the container mapped to /epics/ioc, separately to the /workspace mount.

I don't think opi can be shared because it gets wiped on ioc boot, so inside ioc-xxx could be good.

[gilesknap]

I seem to have missed quite a bit of this conversation.

I think a folder in ioc-xxx is good. This is the approach I have used for ioc for example. I also add a synlink /epics/ioc -> /ioc-xxx/ioc so that its easy to find but exists in the host filesystem so survives devcontainer rebuilds.

Where we put opis is relevant for inter-opi links - but perhaps it is OK if those work via http and you have to go look for the source location to edit them in phoebus? That way accidental edits of generated files would be less likely to be a problem.