fix readme links

README.rst

@@ -1,17 +1,20 @@
-epics-containers
-================
+**epics-containers**
+====================
 
 |docs_ci| |license|
 
 The epics-containers GitHub organization holds a collection of tools and
 documentation for building, deploying and managing containerized EPICS IOCs.
 
+Quick Start
+===========
+
 See `Essential Concepts`_ and the `Getting Started Guide`_ .
 
 Please contribute with comments and suggestions in the wiki or issues pages:
 
-.. _Essential Concepts: https://epics-containers.github.io/user/explanations/introduction.html
-.. _Getting Started Guide: https://epics-containers.github.io/user/tutorials/intro.html
+.. _Essential Concepts: https://epics-containers.github.io/main/user/explanations/introduction.html
+.. _Getting Started Guide: https://epics-containers.github.io/main/user/tutorials/intro.html
 
 ============== ==============================================================
 Documentation  https://epics-containers.github.io

docs/index.rst

@@ -3,45 +3,15 @@
 .. include:: ../README.rst
     :end-before: when included in index.rst
 
-Quick Start
-===========
-
-For a set of tutorials to introduce the concepts of epics-containers see
-`user/tutorials/intro`. For a description of the architecture see
-`essential`.
-
-
 Update for October 2023
 =======================
-The final round of improvements are under way. The latest framework has
+The final round of improvements done. The latest framework has
 become much simpler and has a good developer experience.
 
-The Tutorials are currently out of date and won't work. These should be
-updated to the new Epics Containers Framework by end of Nov 2023.
-
-Update for March 2023
-=====================
-
-Since the documentation for epics-containers was first published in Oct 2021,
-there have been significant updates to the projects in this organization.
-
-The documentation is now being updated to reflect these changes.
-
-Notable improvements are:
-
-- The developer experience has now been improved.
-
-  - Addition of a developer container with all the necessary tools included
-  - Addition of a CLI tool to assist building deploying and managing
-    containerize EPICS IOCs.
-
-- simplified container build approach which minimizes cache busting and
-  improves build times.
+**WARNING**
 
-- Addition of support for IOCS running on MVME5500 with RTEMS 5. (this
-  could be extended to any cross-compiled architectures that use a
-  telnet shell and get their binaries from share file-systems (such as TFTP
-  or NFS))
+The Tutorials are currently out of date and won't work. These are
+being updated now and will be available by end of November 2023.
 
 
 Communication

docs/user/reference/faq.rst

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