sls/hla_framework_bd
0
1
Fork 0
Code Issues 19 Pull Requests 3 Actions Packages Projects 1 Releases Wiki Activity

Merge branch 'main' of gitea.psi.ch:sls/hla_framework_bd into feature/prod-cicd-runner

Browse Source
This commit is contained in:
Benjamin Labrecque
2026-08-27 15:50:27 +02:00
parent 59ce5a900e 132f924e6b
commit e2ab7c9de5
90 changed files with 670 additions and 905 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/developer/ansible.md
-36
View File
@@ -1,36 +0,0 @@
# Ansible
## Running a playbook manually
Set vars on command line:
```
ansible-playbook ansible/playbooks/add-new-service.yml \
-i ansible/hosts.yml \
--extra-vars="repo_root=${{ github.workspace }} agebd_env=dev service_name_lower=<service dir name>" \
-v
```
### Install an IOC
```
ansible-playbook ansible/playbooks/ioc-install.yml \
-i ansible/hosts.yml \
--extra-vars="agebd_env=dev branch_name=feature/add-service-playground service_name_lower=playground ioc_port=50003" \
-v
```
### Start an IOC
```
ansible-playbook ansible/playbooks/ioc-start.yml \
-i ansible/hosts.yml \
--extra-vars="service_name_lower=playground ioc_port=50003" \
-v
```
### Restart an IOC
```
ansible-playbook ansible/playbooks/ioc-restart.yml \
-i ansible/hosts.yml \
--extra-vars="agebd_env=dev branch_name=feature/add-service-playground service_name_lower=playground" \
-v
```
docs/developer/cicd_runner.md
+29 -2
View File
@@ -3,9 +3,11 @@
## Hosts
- `sls-vserv-bd-01(-dev)`
- Runs shellbox commands (and `ioc install ...`?)
- Runs the shellbox commands, which the runner triggers over `ssh`
(see `.gitea/scripts/ioc-start.sh`)
- `sls-vserv-bd-hla01(-dev)`
- Runs everything else
- Runs the runner itself, and therefore everything else: the deployments
to `/sls/bd/hla/<env>/` and the `ioc ...` commands
## Install the runner
@@ -191,3 +193,28 @@ The gitea actions run as user `svcusr-sls2hla`
### #TODO: this is a temporary workaround
I created an ssh key on `sls-vserv-bd-hla01-dev` (where the runner runs), and added the public key to my
gitea profile ssh keys. That way the `svcusr` can clone the repos I can clone.
## Setup `sls-vserv-bd-01-dev`
On `sls-vserv-bd-hla01-dev`
```
sudo su - svcusr-sls2hla
cat ~/.ssh/id_ed25519.pub
```
If it does not exist yet:
```
sudo su - svcusr-sls2hla
ssh-keygen -t ed25519 -N "" -C "svcusr-sls2hla@sls-vserv-bd-hla01-dev" -f ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub
```
```
ssh sls-vserv-bd-01-dev # lands as your own user
sudo install -d -m 700 -o svcusr-sls2hla -g unx-nogroup /home/svcusr-sls2hla /home/svcusr-sls2hla/.ssh
echo '<paste the pubkey>' | sudo tee /home/svcusr-sls2hla/.ssh/authorized_keys
sudo chown svcusr-sls2hla:unx-nogroup /home/svcusr-sls2hla/.ssh/authorized_keys
sudo chmod 600 /home/svcusr-sls2hla/.ssh/authorized_keys
```
docs/developer/ioc/ioc.md
+27 -1
View File
@@ -1,6 +1,8 @@
# IOC
The following instructions explain the basics of starting and managing IOCs on the IOC host.
The following instructions explain the basics of starting and managing IOCs on the IOC host.
They describe the manual steps. In practice the CI/CD runner does this for you, see
[Automation](#automation) below.
- TODO: some iocs not associated to a service, where to put?
- TODO: need to dev/prod template them too
@@ -92,3 +94,27 @@ sudo shellbox start 50045 # start ioc
sudo shellbox log 50045 -f # log file (tail)
exit # exit ssh
```
## Automation
Installing, starting and restarting IOCs is done by the gitea runner, not by hand:
- `.gitea/scripts/ioc-install.sh <service-name> <dev|prod>`
- `.gitea/scripts/ioc-start.sh <service-name> <dev|prod>` (shellbox, over `ssh`)
- `.gitea/scripts/ioc-restart.sh <service-name> <dev|prod>`
The scripts operate on the deployed IOC files in
`/sls/bd/hla/<env>/services/<service-name>/current/ioc`, so a service has to be deployed
before its IOC can be installed.
They run automatically when a new service is added (`.gitea/workflows/add-new-service.yml`).
## Manual CICD Workflow trigger
IOC commands can be triggered manually for any service (or `all` services) through the `Ioc` workflow
(`.gitea/workflows/ioc.yml`) in the gitea Actions tab:
```
Gitea Repo > Actions tab > Ioc (row on left side) > Run Workflow
```
docs/developer/python/epics.md
+27 -2
View File
@@ -62,9 +62,34 @@ Type "help", "copyright", "credits" or "license" for more information.
## Systemd Services
When ssh-ing into a machine, `/etc/profile.d/*` automatically gets sourced.
When ssh-ing into a machine, `/etc/profile.d/*` automatically gets sourced. And thus we have:
```
[sls-vserv-bd-hla01-dev ~]$ env | grep EPICS
EPICS_CA_ADDR_LIST=sls-cagw.psi.ch:5062
```
When running a `systemd` service, this does not happen.
Note -- it seems that the following does not work as expected:
```
That's why we need to source `/etc/profile.d/cas_12_epics.sh` in our startup script
to make sure that `EPICS` is configured properly.
to make sure that `EPICS` is configured properly.
```
After sourcing the script, we still have: `EPICS_CA_ADDR_LIST=` (i.e. the script does not set `EPICS_CA_ADDR_LIST=sls-cagw.psi.ch:5062`) in `systemd` service.
Whereas in the shell `unset EPICS_CA_ADDR_LIST` and then `. /etc/profile/cas_12_epics.sh` properly sets `EPICS_CA_ADDR_LIST=sls-cagw.psi.ch:5062`.
Check which env variables a `systemd` service is running with:
```
[sls-vserv-bd-hla01-dev ~]$ systemctl --user restart AGEBD-SERVICE-SCRUBBING.service && sleep 1 && PID=$(systemctl --user show -p MainPID --value AGEBD-SERVICE-SCRUBBING.service)
[sls-vserv-bd-hla01-dev ~]$ tr '\0' '\n' < /proc/$PID/environ | grep EPICS
EPICS_CAS_IGNORE_ADDR_LIST=
EPICS_CA_ADDR_LIST= 129.129.146.255
EPICS_HOST_ARCH=linux-x86_64
EPICS_BASE_HOST_BIN=/opt/gfa/python-3.10/20220602/epics/bin/linux-x86_64
PYEPICS_LIBCA=/opt/gfa/python-3.10/20220602/epics/lib/linux-x86_64/libca.so
EPICS_BASE_VERSION=7.0.5.0
EPICS_BASE=/opt/gfa/python-3.10/20220602/epics
```