custom initContainer for register-content job

[cognifloyd]

I need to disable most aliases and sensors that are enabled by default in system packs (st2, linux, and packs).
Since I need to adjust the system packs, I need this to do this whenever helm install or helm upgrade changes the system packs but before the content in the system packs gets registered.

Also, I want to ensure that these aliases are never enabled, so merely disabling them via API/UI once enabled is not good enough as that opens up a brief window where people can use !pack install and similar aliases that we don't want users to do via chatops.

I'm planning to use this with #199 (st2.packs.volumes), but it would also make sense when using st2.packs.images. With st2.packs.images, the custom images are copied into the emptyDir first, followed by the system packs (in the packs-initContainers helper template). So, custom images in st2.packs.images cannot change the system packs to disable unwanted aliases.

The helm chart uses {{ .Release.Name }}-job-st2-register-content to run st2-register-content. So, I think the ideal would be to allow for a custom initContainer on that Job. Then the question becomes: Where does such an initContainer definition go in values? st2.packs.registerContentInitContainer? jobs.registerContent.initContainer? Something else?

What should the UX for this look like?

[cognifloyd]

OK. I added one possible approach in #213.

It would allow for something like this in values:

jobs:
  registerContentJob:
    initCommand:
      - '/bin/bash'
      - '-c'
      - |
        sed -i -e 's/^\(\s*\)enabled: true/\1enabled: false/' /opt/stackstorm/packs/packs/aliases/*.yaml
        sed -i -e 's/^\(\s*\)enabled: true/\1enabled: false/' /opt/stackstorm/packs/linux/aliases/*.yaml

I'm not fond of jobs.registerContentJob.initCommand - is there somewhere better to put this?

[cognifloyd]

Maybe jobs.preRegisterContentCommand would be a better name for this, or at least it is less nested.