Open gilesknap opened 10 months ago
@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:-
ibek support develop
mode.This does leave the issue of wanting the paths to be the same inside and outside the container. More thought required.
I think we could solve this by:
ibek develop
command to edit the RELEASE.local
to point to itibek thing-that-links-opis
copy from modules in /epics
and link from things anywhere else/epics/opis
be a volume if we need it to be visible outsideThis way the opi command can get info about what is read-only and what is read-write from its location
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?
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:
<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...
I agree. I want to have think about this - but not sure there is an elegant solution.
@coretl I've remembered the most important reason we should stick with /repos
See https://github.com/epics-containers/ibek/issues/142#issuecomment-1819261178
Ok, so if we stick with /workspace
(as we decided on in #142), then here are the options I can think 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
...
Wouldn't ioc-adaravis
and ioc-pilatus
just both use /workspace/ADCore
inside the container?
so you would have?
- arbitrary_path/
- ioc-adaravis/
- ioc-adpilatus/
- opis/
- ADCore/
- ADAravis/
- ADPilatus/
Shared opi
directory between them?
Or stick the opis
directory inside ioc-xxx
?
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.
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.
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.