@@ -5,15 +5,8 @@ Frequently Asked Questions
5
5
6
6
Why no mention of Operator Interfaces?
7
7
--------------------------------------
8
- OPI was out of scope for the proof of concept. That is because we
9
- expect there to be a web based EPICS OPI available by the time we go
10
- live with K8s IOCs. Kubernetes is very well suited to running web
11
- servers so this is a natural fit.
12
-
13
- There are a number of ways to support the current OPI solutions without
14
- breaking the repositories-only model. The simplest approach is to extract
15
- the OPI files from the container running in Kubernetes with **kubectl cp **.
16
- Then keep a local cache and run the OPI code locally.
8
+ UPDATE: with the introduction of PVI we are providing auto generated
9
+ engineering screens. TODO: more details will be added to a new section.
17
10
18
11
19
12
Why have ioc-XXX repositories?
@@ -51,10 +44,9 @@ It is also necessary for Kubernetes to be able to pull the Generic IOC image. If
51
44
the beamline has only one Kubernetes worker node then the previous image will
52
45
be in the node's local cache. If you have more than one then you will need
53
46
a global image cache which is useful anyway for reducing traffic to the
54
- registries (JetStack have performed a POC for DLS that demonstrates such a
55
- global cache)
47
+ registries. At DLS we have a global cache for all container registry
48
+ interactions, it uses Harbour. See https://goharbor.io/ for more details.
56
49
57
50
Note that making changes to an IOC and spinning them up would not be possible
58
- if all registries were in the cloud. However it is recommended that the 'work'
59
- registries are on prem. The production helm registry is also likely to be on
60
- prem since there is little benefit in sharing a facility's IOC instances.
51
+ if all registries were in the cloud and the internet connection had failed.
52
+ However it is recommended that the 'work' registries are on premises.
0 commit comments