Closed anthonysomerset closed 2 months ago
@anthonysomerset Would you mind please how your code is then sourced?
This one:
puppetdb:
tag: 7.18.0-v1.5.0
extraEnv:
PUPPETDB_POSTGRES_HOSTNAME: dbhostname.postgres.database.azure.com
customconfigs:
enabled: true
configmaps:
database.conf: |-
database: {
subname: "//"${PUPPETDB_POSTGRES_HOSTNAME}":"${PUPPETDB_POSTGRES_PORT}"/"${PUPPETDB_POSTGRES_DATABASE}
username: ${PUPPETDB_USER}
password: ${PUPPETDB_PASSWORD}
node-ttl: ${PUPPETDB_NODE_TTL}
node-purge-ttl: ${PUPPETDB_NODE_PURGE_TTL}
report-ttl: ${PUPPETDB_REPORT_TTL}
facts-blocklist: ".*veth.*"
facts-blocklist-type: regex
}
this is basically an example reference values.yaml that i used for testing and validation that the deployment works
the extraEnv for the db hostname was to respond to the referenced issue where the user needed to use an external DB and thus customconfigs is NOT required in their case anyway
the custom config was my example and use case of setting a facts-blocklist as a valid customconfig that did need such (and now works)
is that what you were looking for?
@anthonysomerset Sorry, I am probably missing something but aren't you eliminating here the possibility the above to be sourced?
no - it now works without generating an error as in #215
The configmap is an example to override database.conf, all but the last 2 lines are default config i am replaying for safety sake - might not be needed but haven't verified further either at this stage
fixes #215 and allows customconfigs deployments in puppetdb by removing the duplicate volume mount block