Binarystore.xml on Kubernetes is passed to artifactory as a secret. You can modify values.yaml to control the secret being generated and thus control binarystore.xml.
In general, most of the properties you need set with filestore are implemented as properties in values.yaml. If changing properties does not give the binarystore.xml you want, you can pass the full template as outlined here https://github.com/jfrog/charts/tree/master/stable/artifactory-ha#custom-binarystorexml
If you found out that changes to binarystore.xml is not being respected. You should check these places according to orders:
- values.yaml
- Secret ( Ends with "--binarystore")
- /artifactory_extra_conf/binarystore.xml (inside the pod)
- /var/opt/jfrog/artifactory/etc/binarystore.xml (inside the pod)
At 1, check if values.yaml has been modified. If you are modifying binarystore.xml with values.yaml, check if you have provided the correct values.
At 2, check the secret.
The secret name can be either
{{ .Values.artifactory.persistence.customBinarystoreXmlSecret }}
Or
{{ template "artifactory-ha.fullname" . }}-binarystore
The first one is when you pass your own secret, the second one is when you rely on values.yaml to create the secret.
Describe the secret to see if it has the correct value and key
At 3, check /artifactory_extra_conf/binarystore.xml inside the pod. If this is not the correct value, things went wrong in step 2 or 1. You might also want to describe the pod to check if the pod is mounting the correct secret.
At 4, /var/opt/jfrog/artifactory/etc/binarystore.xml inside the pod. If you see the correct binarystore.xml in step 3, but not 4, make sure you uncomment this in values.yml
copyOnEveryStartup:
# # Absolute path
# - source: /artifactory_extra_conf/binarystore.xml
# # Relative to ARTIFACTORY_HOME/
# target: etc/
Manually delete binarystore.xml under /var/opt/jfrog/artifactory/etc/binarystore.xml helps too.
Last, remember you need to restart artifactory by killing the pod.