tutorial fixes done up to "Create IOC Instance"

Author: gilesknap

.gitignore

@@ -68,3 +68,6 @@ lockfiles/
 
 # ruff cache
 .ruff_cache/
+
+# workspace files
+**/*.code-workspace

docs/conf.py

@@ -14,7 +14,7 @@
 version = "1.0"
 
 # General information about the project.
-project = "epics-containers.github.io"
+project = "epics-containers"
 
 extensions = [
     # Use this for generating API docs

docs/tutorials/create_beamline.md

@@ -51,7 +51,7 @@ assets. See `../explanations/repositories`.
 
 ## Steps
 
-1. Go to your GitHub account home page. Click on 'Repositories' and then 'New', give your new repository the name `bl01t` plus a description, then click 'Create'.
+1. Go to your GitHub account home page. Click on 'Repositories' and then 'New', give your new repository the name `bl01t` plus a description, then click 'Create repository'.
 
    If you are using an alternative to GitHub for your repositories then
    see [these instructions] for an alternative approach.
@@ -61,7 +61,7 @@ assets. See `../explanations/repositories`.
       ```bash
       pip install copier
       # this will create the folder bl01t in the current directory
-      copier copy gh:epics-containers/ec/services-template --trust bl01t
+      copier copy gh:epics-containers/ec-services-template --trust bl01t
       ```
 1. Answer the copier template questions as follows:
 

docs/tutorials/create_ioc.md

@@ -12,20 +12,13 @@ across AreaDetector: <https://areadetector.github.io/master/index.html>.
 
 ## Create a New IOC Instance
 
-To create a new IOC Instance simply add a new folder to the `iocs` folder
-in your beamline repo. The name of the folder will be the name of the IOC.
-This folder needs to contain these two items:
+To create a new IOC Instance simply add a new folder to the `services` folder in your beamline repo. The name of the folder will be the name of the IOC. This folder needs to contain these two items:
 
 ```{eval-rst}
-
-:config:
-
-    a folder that contains the IOC configuration files. The configuration
-    can take a number of forms
-    `listed here <https://github.com/epics-containers/ibek/blob/ea9da7e1cfe88f2a300ad236f820221837dd9dcf/src/ibek/templates/ioc/config/start.sh>`_.
-
-values.yaml
-~~~~~~~~~~~~~~~~~~~~~~~
+===================    =======================================================
+**config**             A folder that contains the IOC configuration files. The configuration can take a number of forms [listed here](https://github.com/epics-containers/ioc-template/blob/main/ioc/start.sh).
+**values.yaml**        A helm chart values override file. The only required field is ``image`` which determines which Generic IOC container the IOC Instance will run in. However, any other fields in the helm chart values file can be overridden on a per IOC instance basis in this file. See the shared values.yaml file in the ``helm/shared`` folder for a complete list of fields that can be overridden.
+===================    =======================================================
 ```
 
 ### values.yaml
@@ -49,10 +42,10 @@ container. This container was built by the Generic IOC source repo here
 <https://github.com/epics-containers/ioc-adsimdetector>. The container has
 support for AreaDetector and ADSimDetector compiled into its IOC binary.
 
-Generic IOCs have compiled IOC binaries and `dbd` files but no startup script or
+Generic services have compiled IOC binaries and `dbd` files but no startup script or
 EPICS database. The compiled IOC binary, `dbds` and support `lib` files
 are baked into the container at container build time. This means that the
-code for making IOCs for a given class of device need only be compiled once
+code for making services for a given class of device need only be compiled once
 and can be reused for many IOC Instances.
 
 A startup script and EPICS Database are provided by the IOC Instance at
@@ -304,7 +297,7 @@ the c2dv viewer showing an image from the example IOC
 
 Above we looked at some ibek *Support yaml* and created an *IOC yaml* file.
 The details of where *Support yaml* files come from and how to create your
-own are covered in later tutorials on creating Generic IOCs.
+own are covered in later tutorials on creating Generic services.
 
 However, without looking into the set of *Support yaml* files that are
 inside a given Generic IOC we can still make a meaningful *IOC yaml* file.

docs/tutorials/deploy_example.md

@@ -164,14 +164,7 @@ bl01t-ea-test-01     2024.2.1           Up 4 seconds        ghcr.io/epics-contai
 
 ### IMPORTANT: deploy-local vs deploy
 
-Be aware of the distinction of `deploy-local` vs `deploy`. Both of these
-commands create a running instance of the IOC in the target environment (currently
-your local machine - later on a Kubernetes Cluster). However, `deploy-local`
-gets the IOC instance description YAML direct from your local filesystem. This
-means it is not likely to be available for re-deployment later on. `deploy`
-gets the IOC instance description YAML from the GitHub repository with able
-specific tag and therefore is a known state that can be recovered at a later
-date.
+Be aware of the distinction of `deploy-local` vs `deploy`. Both of these commands create a running instance of the IOC in the target environment (currently your local machine - later on a Kubernetes Cluster). However, `deploy-local` gets the IOC instance description YAML direct from your local filesystem. This means it is not likely to be available for re-deployment later on. `deploy` gets the IOC instance description YAML from the GitHub repository with a specific tag and therefore is a known state that can be recovered at a later date.
 
 Always strive to have released versions of IOC instances deployed in your
 environments. `deploy-local` is only for temporary testing purposes.

docs/tutorials/intro.md

@@ -9,17 +9,16 @@ and should be possible to work through without any prior knowledge.
 However, to get the most out of the tutorials it would be best to start with
 some background in the following topics.
 
-- An introduction to containers <https://www.docker.com/resources/what-container/>
-- Managing containers on a workstation: introduction to docker
-  <https://docs.docker.com/get-started/overview/>
-- Podman, a recommended docker alternative
-  <https://docs.podman.io/en/latest/Introduction.html>
-- Orchestrating containers in a cluster with Kubernetes
-  <https://kubernetes.io/docs/concepts/overview/>
-- Managing packages in a Kubernetes Cluster with Helm
-  <https://helm.sh/docs/intro/quickstart/>
-- Introduction to EPICS
-  <https://docs.epics-controls.org/en/latest/guides/EPICS_Intro.html>
+```{eval-rst}
+================================================================    ================
+**An introduction to containers**                                   <https://www.docker.com/resources/what-container/>
+**Managing containers on a workstation: introduction to docker**    <https://docs.docker.com/get-started/overview/>
+**Podman, a recommended docker alternative**                        <https://docs.podman.io/en/latest/Introduction.html>
+**Orchestrating containers in a cluster with Kubernetes**           <https://kubernetes.io/docs/concepts/overview/>
+**Managing packages in a Kubernetes Cluster with Helm**             <https://helm.sh/docs/intro/quickstart/>
+**Introduction to EPICS**                                           <https://docs.epics-controls.org/en/latest/guides/EPICS_Intro.html>
+================================================================    ================
+```
 
 With the above background in hand you should then read the overview of
 epics-containers architecture here: {any}`../explanations/introduction`