-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local HTTP server #134
Comments
@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:-
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:
This 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 ...
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 |
The only issue with this is that if
|
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 |
Ok, so if we stick with
The second requires more thought to allow @GDYendell 's use-case of using the same dev |
Wouldn't |
so you would have?
Shared |
Or stick the |
I think it doesn't matter where the I don't think |
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 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.
The text was updated successfully, but these errors were encountered: