Closed konrad-garus closed 10 months ago
@konrad-garus thanks for your questions. I am afraid we can't get rid of shared home as such but what I think is possible is either:
I haven't tried it myself though but happy to verify it if it's something that somehow addresses the raised issue.
Why not get rid of shared home? Confluence is perfectly happy without it, as long as it's a single-node deployment. Which is what I'm asking for here.
In fact, we've recently talked about it for Bitbucket: https://github.com/atlassian/data-center-helm-charts/issues/379.
Right now I'm using Kustomize for it and it works just fine. What I'm suggesting here is to make it a part of the official chart, to support single-node deployments.
My Kustomize patches look like this:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: confluence
spec:
template:
spec:
containers:
- name: confluence
env:
- $patch: delete
name: ATL_PRODUCT_HOME_SHARED
volumeMounts:
- $patch: replace
- name: local-home
mountPath: /var/atlassian/application-data/confluence
volumes:
- $patch: delete
# By replacing additional_jvm_args, this update does two things:
#
# 1. It removes the config params that configure standalone Synchrony
# 2. It tweaks Confluence configuration to have better behavior around job purge (causing excessive DB load)
#
# The default args (as of 1.5.1) are:
# -Dconfluence.cluster.hazelcast.listenPort=5701
# -Dsynchrony.btf.disabled=true
# -Dsynchrony.by.default.enable.collab.editing.if.manually.managed=true
# -Dconfluence.clusterNodeName.useHostname=true
# -Datlassian.logging.cloud.enabled=false
# -XX:ActiveProcessorCount=1
apiVersion: v1
kind: ConfigMap
metadata:
name: confluence-jvm-config
data:
additional_jvm_args: -Djobs.limit.per.purge=50000 -Dall.jobs.ttl.hours=168
apiVersion: v1
kind: Service
metadata:
name: confluence
spec:
ports:
- name: synchrony
port: 8091
targetPort: 8091
protocol: TCP
Hi @konrad-garus sorry for not getting back to you earlier. Your Kustomize now makes sense to me. One question though - what's local-home volumeMount is replaced with?
I guess, we may add a few conditions to drop shared home env var and shared home volumeMount and volume altogether.
As to the synchrony, as far as I understand you may control everything in values.yaml through additional jvm args?
Maybe get rid of local home instead. If you do not customize the deployment there are probably just a few files needed to be persistent in local home, as the important stuff goes into shared home. If possible to accommodate those few files perhaps make shared home read-write-once if single node to improve performance, and read-write-many only if multi-node. Also, since synchrony statefulset is the same image reducing the pods does seem ideal. Sometimes getting all 4 pods to boot is quite painful.
as for synchrony: it is possible to deploy managed synchrony with the data center chart. Meaning no synchrony statefulset at all, just the managed synchrony in each confluence pod. No changes to the chart or image nexessary, only creative overrides.
@bordenit it is possible to have a custom volume for shared-home and make it RWO (of course if you do not plan to scale StatefulSet). Local home is optional, it is emptyDir by default and the downside of not persisting local-home is the necessity to recover indexes each time the pod restarts.
We won't be implementing it at this time as Helm charts target deployments at scale. It is still possible to use a custom RWO volume for shared home.
Suggestion
It would be nice if the Confluence chart supported single-node deployments. You don't always need the hassle and additional costs of additional volumes, processes (Synchrony) etc.
ATL_PRODUCT_HOME_SHARED
env var.Product
Confluence
Code of Conduct