Moving gitea to debian host and updating opi5 storage to ssd instead of nvme
This commit is contained in:
parent
207f7274fe
commit
39d500866c
17
README.md
17
README.md
|
|
@ -157,12 +157,11 @@ applies the edge stack.
|
|||
Set `LAB_PIMOX_PIPELINE=false` to skip Pimox automation. Set
|
||||
`LAB_PIMOX_WORKER_COUNT=0` to create or refresh only the template. The pipeline
|
||||
keeps the template on its configured `local` storage, creates new worker VM
|
||||
clones on `nvme_storage` by default when that Pimox storage is available,
|
||||
clones on `opi5_ssd` by default when that Pimox storage is available,
|
||||
checks that the Pimox bridge already exists, refuses `local` as worker clone
|
||||
storage, and refuses to edit Orange Pi host networking. The current stable bulk
|
||||
storage path is the HP Debian laptop's `data-vg`, mounted under `/data`; do not
|
||||
place worker root disks on the Orange Pi USB/NVMe path unless it has been
|
||||
revalidated.
|
||||
storage, and refuses to edit Orange Pi host networking. Keep durable data on
|
||||
the HP Debian laptop's `data-vg` or external backups; treat Orange Pi VM disks
|
||||
as rebuildable worker capacity.
|
||||
|
||||
`LAB_PIMOX_SKIP_WORKER_INDEXES` defaults to an empty value, so the pipeline owns
|
||||
worker index `1` and VMID `9010` when `LAB_PIMOX_WORKER_COUNT=1`. Set
|
||||
|
|
@ -232,12 +231,12 @@ For Pimox on Orange Pi 5 Plus, `./lab.sh up` can create the Debian 13 arm64
|
|||
template and worker VM clones automatically when the Orange Pi storage path is
|
||||
healthy. Defaults are intentionally tied to the observed host: Pimox SSH host
|
||||
`192.168.100.80`, bridge `vmbr0`, template VMID `9000` on `local` storage, two
|
||||
4 GiB worker VMs starting at VMID `9010`, worker clone storage `nvme_storage`,
|
||||
4 GiB worker VMs starting at VMID `9010`, worker clone storage `opi5_ssd`,
|
||||
and no CPU affinity because this Pimox is pinned to Debian Bullseye. The NVMe
|
||||
that was previously attached to the Orange Pi now belongs to the HP Debian
|
||||
laptop as LVM volume group `data-vg`, so treat Orange Pi VM storage as optional
|
||||
until a stable Pimox-backed datastore is configured. Details and override
|
||||
variables are in
|
||||
laptop as LVM volume group `data-vg`; the current Orange Pi SSD-backed Pimox
|
||||
datastore is `opi5_ssd` and is used for rebuildable VM root disks. Details and
|
||||
override variables are in
|
||||
`bootstrap/provisioning/README.md`.
|
||||
|
||||
Worker indexes are stable. Index `1` maps to VMID `9010`, node name
|
||||
|
|
|
|||
|
|
@ -63,8 +63,16 @@
|
|||
- name: Add Helm apt key
|
||||
ansible.builtin.shell: |
|
||||
set -euo pipefail
|
||||
curl -fsSL https://baltocdn.com/helm/signing.asc |
|
||||
gpg --dearmor >/etc/apt/keyrings/helm.gpg
|
||||
helm_key_fingerprint="DDF78C3E6EBB2D2CC223C95C62BA89D07698DBC6"
|
||||
tmp_key="$(mktemp)"
|
||||
trap 'rm -f "${tmp_key}"' EXIT
|
||||
curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey >"${tmp_key}"
|
||||
actual_fingerprint="$(gpg --show-keys --with-colons "${tmp_key}" | awk -F: '$1 == "fpr" { print $10; exit }')"
|
||||
if [ "${actual_fingerprint}" != "${helm_key_fingerprint}" ]; then
|
||||
echo "Unexpected Helm apt key fingerprint: ${actual_fingerprint}" >&2
|
||||
exit 1
|
||||
fi
|
||||
gpg --dearmor <"${tmp_key}" >/etc/apt/keyrings/helm.gpg
|
||||
chmod 0644 /etc/apt/keyrings/helm.gpg
|
||||
args:
|
||||
executable: /bin/bash
|
||||
|
|
@ -75,7 +83,7 @@
|
|||
dest: /etc/apt/sources.list.d/helm-stable-debian.list
|
||||
mode: "0644"
|
||||
content: |
|
||||
deb [arch={{ ansible_facts.architecture | regex_replace('x86_64', 'amd64') | regex_replace('aarch64', 'arm64') }} signed-by=/etc/apt/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main
|
||||
deb [arch={{ ansible_facts.architecture | regex_replace('x86_64', 'amd64') | regex_replace('aarch64', 'arm64') }} signed-by=/etc/apt/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main
|
||||
|
||||
- name: Add OpenTofu apt keys
|
||||
ansible.builtin.shell: |
|
||||
|
|
|
|||
|
|
@ -112,13 +112,13 @@ networking, virtio-scsi disk, `vmbr0`, `local` template storage, 1 socket with
|
|||
`./lab.sh up` also creates or reuses worker clones after the template exists. It
|
||||
defaults to one worker, VMID `9010`, name `pimox-worker-01`, deterministic
|
||||
locally administered MAC address, 1 socket
|
||||
with 2 cores, 4 GiB RAM, `nvme_storage` clone storage, and qemu-guest-agent IP
|
||||
with 2 cores, 4 GiB RAM, `opi5_ssd` clone storage, and qemu-guest-agent IP
|
||||
discovery when that Pimox storage is available. New workers are full clones
|
||||
created with `qm clone --storage`, so the template can remain on `local` while
|
||||
worker disks land on a non-local Pimox datastore. The USB/NVMe device that was
|
||||
previously attached to the Orange Pi now backs the HP Debian laptop's `data-vg`,
|
||||
so revalidate or replace the Pimox datastore before creating worker root disks
|
||||
there again. Set `LAB_PIMOX_WORKER_REPLACE_EXISTING=true` to
|
||||
worker disks land on the Orange Pi SSD-backed non-local Pimox datastore. Keep
|
||||
durable data on the HP Debian laptop's `data-vg` or external backups and treat
|
||||
Orange Pi VM disks as rebuildable worker capacity. Set
|
||||
`LAB_PIMOX_WORKER_REPLACE_EXISTING=true` to
|
||||
destroy and recreate existing worker VMs from the current template. The pipeline
|
||||
refuses `LAB_PIMOX_WORKER_STORAGE=local` so only the template VM lives on local
|
||||
storage.
|
||||
|
|
@ -162,7 +162,7 @@ Defaults:
|
|||
|
||||
- VMID `9100`
|
||||
- VM name `openwrt-firewall`
|
||||
- disk storage `nvme_storage` when that Pimox storage is available
|
||||
- disk storage `opi5_ssd` when that Pimox storage is available
|
||||
- WAN bridge `vmbr0`
|
||||
- LAN bridge `vmbr1`
|
||||
- LAN address `192.168.50.1/24`
|
||||
|
|
|
|||
16
lab.sh
16
lab.sh
|
|
@ -894,7 +894,7 @@ run_pimox_pipeline() {
|
|||
local worker_memory="${LAB_PIMOX_WORKER_MEMORY:-4096}"
|
||||
local worker_cpu_affinities="${LAB_PIMOX_WORKER_CPU_AFFINITIES:-}"
|
||||
local worker_replace_existing="${LAB_PIMOX_WORKER_REPLACE_EXISTING:-false}"
|
||||
local worker_storage="${LAB_PIMOX_WORKER_STORAGE:-${TF_VAR_pimox_worker_storage:-nvme_storage}}"
|
||||
local worker_storage="${LAB_PIMOX_WORKER_STORAGE:-${TF_VAR_pimox_worker_storage:-opi5_ssd}}"
|
||||
local worker_user="${LAB_PIMOX_WORKER_USER:-jv}"
|
||||
local worker_key_path="${LAB_PIMOX_WORKER_SSH_KEY_PATH:-/home/jv/.ssh/id_ed25519}"
|
||||
local ip_prefix="${LAB_PIMOX_GUEST_IP_PREFIX:-192.168.100.}"
|
||||
|
|
@ -956,6 +956,18 @@ fi
|
|||
if ! sudo -n true >/dev/null 2>&1; then
|
||||
echo 'passwordless sudo is not available for ${pimox_user}'
|
||||
exit 1
|
||||
fi
|
||||
pvesm_cmd=\"\$(command -v pvesm 2>/dev/null || true)\"
|
||||
if [ -z \"\$pvesm_cmd\" ] && [ -x /usr/sbin/pvesm ]; then
|
||||
pvesm_cmd=/usr/sbin/pvesm
|
||||
fi
|
||||
if [ -z \"\$pvesm_cmd\" ]; then
|
||||
echo 'pvesm was not found; cannot validate Pimox worker storage ${worker_storage}'
|
||||
exit 1
|
||||
fi
|
||||
if ! sudo \"\$pvesm_cmd\" status | awk -v storage='${worker_storage}' 'NR > 1 && \$1 == storage && \$3 == \"active\" { found = 1 } END { exit found ? 0 : 1 }'; then
|
||||
echo 'Pimox worker storage ${worker_storage} was not found or is not active'
|
||||
exit 1
|
||||
fi" 2>&1)"
|
||||
readiness_status=$?
|
||||
set -e
|
||||
|
|
@ -1054,7 +1066,7 @@ run_openwrt_pipeline() {
|
|||
local qm_bin="${LAB_PIMOX_QM_BIN:-${TF_VAR_pimox_qm_bin:-/usr/sbin/qm}}"
|
||||
local vmid="${LAB_OPENWRT_VMID:-9100}"
|
||||
local vm_name="${LAB_OPENWRT_NAME:-openwrt-firewall}"
|
||||
local storage="${LAB_OPENWRT_STORAGE:-nvme_storage}"
|
||||
local storage="${LAB_OPENWRT_STORAGE:-opi5_ssd}"
|
||||
local wan_bridge="${LAB_OPENWRT_WAN_BRIDGE:-vmbr0}"
|
||||
local lan_bridge="${LAB_OPENWRT_LAN_BRIDGE:-vmbr1}"
|
||||
local cores="${LAB_OPENWRT_CORES:-2}"
|
||||
|
|
|
|||
Loading…
Reference in New Issue