tika: Update to 3.2.2.0

Revert "music-assistant: Tell players to restart on startup"
This hacky work-around is no longer necessary, as I've figured out why the players don't (always) get rediscovered when the server restarts. It turns out, Avahi on the firewall was caching responses to the mDNS PTR requests Music Assistant makes. Rather than forward the requests to the other VLANs, it would respond with its cached information, but in a way that Music Assistant didn't understand. Setting `cache-entries-max` to `0` in `avahi-daemon.conf` on the firewall resolved the issue. This reverts commit 42a7964991.
2025-08-16 11:32:09 +00:00 · 2025-08-12 20:17:52 -05:00 · 2025-08-11 21:00:02 -05:00 · 2025-08-11 20:59:54 -05:00 · 2025-08-11 20:43:28 -05:00 · 2025-08-10 17:43:02 -05:00
6 changed files with 163 additions and 0 deletions
--- a/calico/kustomization.yaml
+++ b/calico/kustomization.yaml
@ -0,0 +1,10 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+labels:
+- pairs:
+    app.kubernetes.io/instance: calico
+
+resources:
+- https://raw.githubusercontent.com/projectcalico/calico/v3.30.2/manifests/operator-crds.yaml
+- https://raw.githubusercontent.com/projectcalico/calico/v3.30.2/manifests/tigera-operator.yaml
--- a/dch-webhooks/jenkins.yaml
+++ b/dch-webhooks/jenkins.yaml
@ -0,0 +1,28 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: jenkins.dch-webhooks
+rules:
+  - apiGroups:
+    - apps
+    resources:
+    - deployments
+    resourceNames:
+    - dch-webhooks
+    verbs:
+    - get
+    - patch
+
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: jenkins.dch-webhooks
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: jenkins.dch-webhooks
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: jenkins-jobs
--- a/music-assistant/ingress.yaml
+++ b/music-assistant/ingress.yaml
@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: music-assistant
+  labels:
+    app.kubernetes.io/name: music-assistant
+    app.kubernetes.io/component: music-assistant
+spec:
+  ingressClassName: nginx
+  rules:
+  - host: music.pyrocufflink.blue
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: music-assistant
+            port:
+              name: http
--- a/music-assistant/kustomization.yaml
+++ b/music-assistant/kustomization.yaml
@ -0,0 +1,21 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+namespace: music-assistant
+
+labels:
+- pairs:
+    app.kubernetes.io/instance: music-assistant
+  includeSelectors: true
+- pairs:
+    app.kubernetes.io/part-of: music-assistant
+  includeTemplates: true
+
+resources:
+- namespace.yaml
+- music-assistant.yaml
+- ingress.yaml
+
+images:
+- name: ghcr.io/music-assistant/server
+  newTag: 2.6.0b18
--- a/music-assistant/music-assistant.yaml
+++ b/music-assistant/music-assistant.yaml
@ -0,0 +1,78 @@
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: music-assistant
+  labels: &labels
+    app.kubernetes.io/name: music-assistant
+    app.kubernetes.io/component: music-assistant
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: music-assistant
+  labels: &labels
+    app.kubernetes.io/name: music-assistant
+    app.kubernetes.io/component: music-assistant
+spec:
+  ports:
+  - port: 8095
+    name: http
+  selector: *labels
+
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: music-assistant
+  labels: &labels
+    app.kubernetes.io/name: music-assistant
+    app.kubernetes.io/component: music-assistant
+spec:
+  serviceName: music-assistant
+  selector:
+    matchLabels: *labels
+  template:
+    metadata:
+      labels: *labels
+    spec:
+      containers:
+      - name: music-assistant
+        image: ghcr.io/music-assistant/server
+        imagePullPolicy: IfNotPresent
+        ports:
+        - containerPort: 8095
+          name: http
+        readinessProbe: &probe
+          httpGet:
+            port: http
+            path: /
+          failureThreshold: 3
+          periodSeconds: 60
+          successThreshold: 1
+          timeoutSeconds: 1
+        startupProbe:
+          <<: *probe
+          failureThreshold: 90
+          periodSeconds: 1
+        volumeMounts:
+          - mountPath: /data
+            name: music-assistant-data
+            subPath: data
+      dnsPolicy: ClusterFirstWithHostNet
+      hostNetwork: true
+      securityContext:
+        runAsNonRoot: true
+        runAsUser: 8095
+        runAsGroup: 8095
+        fsGroup: 8095
+      volumes:
+      - name: music-assistant-data
+        persistentVolumeClaim:
+          claimName: music-assistant
--- a/music-assistant/namespace.yaml
+++ b/music-assistant/namespace.yaml
@ -0,0 +1,6 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: music-assistant
+  labels:
+    app.kubernetes.io/name: music-assistant
Author	SHA1	Message	Date
bot	f24285d761	tika: Update to 3.2.2.0	2025-08-16 11:32:09 +00:00
Dustin	8a6b41bacc	Revert "music-assistant: Tell players to restart on startup" This hacky work-around is no longer necessary, as I've figured out why the players don't (always) get rediscovered when the server restarts. It turns out, Avahi on the firewall was caching responses to the mDNS PTR requests Music Assistant makes. Rather than forward the requests to the other VLANs, it would respond with its cached information, but in a way that Music Assistant didn't understand. Setting `cache-entries-max` to `0` in `avahi-daemon.conf` on the firewall resolved the issue. This reverts commit `42a7964991`.	2025-08-12 20:17:52 -05:00
Dustin	e0e3eab8b6	Merge branch 'music-assistant'	2025-08-11 21:00:02 -05:00
Dustin	42a7964991	music-assistant: Tell players to restart on startup I haven't fully determined why, but when the Music Assistant server restarts, it marks the _shairport-sync_ players as offline and will not allow playing to them. The only way I have found to work around this is to restart the players after the server restarts. As that's pretty cumbersome and annoying, I naturally want to automate it, so I've created this rudimentary synchronization technique using _ntfy_: each player listens for notifications on a specific topic, and upon receiving one, tells _shairport-sync_ to exit. With the `Restart=` property configured on the _shairport-sync.service_ unit, _systemd_ will restart the service, which causes Music Assistant to discover the player again.	2025-08-11 20:59:54 -05:00
Dustin	ae1d952297	music-assistant: Initial deployment _Music Assistant_ is pretty straightforward to deploy, despite upstream's apparent opinion otherwise. It just needs a small persistent volume for its media index and customization. It does need to use the host network namespace, though, in order to receive multicast announcements from e.g. AirPlay players, as it doesn't have any way of statically configuring them.	2025-08-11 20:43:28 -05:00
Dustin	4977f513c5	dch-webhooks: Add role for Jenkins to deploy Jenkins needs to be able to patch the Deployment to trigger a restart after it builds a new container image for _dch-webhooks_. Note that this manifest must be applied on its own without Kustomize. Kustomize seems to think the `dch-webhooks` in `resourceNames` refers to the ConfigMap it manages and "helpfully" renames it with the name suffix hash. It's _not_ the ConfigMap, though, but there's not really any way to tell it this.	2025-08-10 17:43:02 -05:00
Dustin	3960552f99	calico: Update to v3.30.2	2025-08-08 11:00:27 -05:00