@akosiaris or @Joe, the current /srv/mediawiki-staging/private appears to be a local git repo with no remotes. Do you know if this repo/files live anywhere else? Any thoughts on the idea of syncing/moving them into a k8s Secret?

In T271475#6765888, @dduvall wrote:

@akosiaris or @Joe, the current /srv/mediawiki-staging/private appears to be a local git repo with no remotes. Do you know if this repo/files live anywhere else?

It shouldn't, as far as I know.

Any thoughts on the idea of syncing/moving them into a k8s Secret?

It is barely 36K, it definitely fits (limit is 1MB). So it makes perfect sense to have those 6 files in a Secret and mount them on the mw container. The question that arises from my side though is about the UX of deployers, we 'll need to keep it sane. Probably something like the following in the helm chart (with a question mark regarding absolute paths) would allow a similar experience.

apiVersion: v1
kind: Secret
metadata:
  name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}

In T271475#6769055, @akosiaris wrote:

In T271475#6765888, @dduvall wrote:

Any thoughts on the idea of syncing/moving them into a k8s Secret?

It is barely 36K, it definitely fits (limit is 1MB). So it makes perfect sense to have those 6 files in a Secret and mount them on the mw container. The question that arises from my side though is about the UX of deployers, we 'll need to keep it sane. Probably something like the following in the helm chart (with a question mark regarding absolute paths) would allow a similar experience.

apiVersion: v1
kind: Secret
metadata:
  name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}

Is the overall idea to keep the private files where they currently live and source them from the local filesystem during helmfile apply to create the k8s secret? Off the top of my head that seems workable and it definitely maintains the current expectations/workflow around those private settings. @jeena or @dancy do you have thoughts?

In T271475#6769543, @dduvall wrote:

In T271475#6769055, @akosiaris wrote:

In T271475#6765888, @dduvall wrote:

Any thoughts on the idea of syncing/moving them into a k8s Secret?

It is barely 36K, it definitely fits (limit is 1MB). So it makes perfect sense to have those 6 files in a Secret and mount them on the mw container. The question that arises from my side though is about the UX of deployers, we 'll need to keep it sane. Probably something like the following in the helm chart (with a question mark regarding absolute paths) would allow a similar experience.

apiVersion: v1
kind: Secret
metadata:
  name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}

Is the overall idea to keep the private files where they currently live and source them from the local filesystem during helmfile apply to create the k8s secret? Off the top of my head that seems workable and it definitely maintains the current expectations/workflow around those private settings.

Yes, that has been my approach. We can always revisit, but I expect that keeping the workflow similar will facilitate the migration.

Sounds like these can stay where they are and the work that remains is add the ability to source the private settings at deploy time in the chart.

In T271475#6769055, @akosiaris wrote:

It is barely 36K, it definitely fits (limit is 1MB). So it makes perfect sense to have those 6 files in a Secret and mount them on the mw container. The question that arises from my side though is about the UX of deployers, we 'll need to keep it sane. Probably something like the following in the helm chart (with a question mark regarding absolute paths) would allow a similar experience.

apiVersion: v1
kind: Secret
metadata:
  name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}

I've been experimenting with this and I don't think it will work for secret files. When packaging the chart, Helm will expect the files to be in the chart's directory, and will add them to the chart package. We don't want the secret files to end up in the published chart. See these issues for more info: https://github.com/helm/helm/issues/3276, https://github.com/helm/helm/issues/1754

There are a few options I've thought of so far:

1. If we didn't publish the chart, we could add the secret files to the chart directory or use a symbolic link to the secret files and use the chart directory when deploying Mediawiki, instead of a published chart, but we'd still need to stop our automated process from packaging and publishing the chart with secrets.
2. Using the same method as above, but having a separate chart just for the secrets, which could then be referenced by the Mediawiki chart. Then the Mediawiki chart could be published.
3. Use --set-file when deploying the chart, which will add the contents of the file to the chart values under the specified key. Unfortunately this method can't ingest a directory, so each file would have to be added separately using set-file. Ex: helm install --set-file secret=/path/to/super-secret/
4. Use kubectl directly to deploy the secrets to k8s each time they are updated. @akosiaris I assume this would be discouraged, and as far as I understand would be annoying because we wouldn't be able to add a checksum to the helm chart to restart the pod if the secrets changed.

Discussed in the sync-up meeting that we may also add the PrivateSettings files into the production docker image as a second build step.