Revert enabled parameter

[marcelldls]

This allows <service>.enabled to be applied from the deployment repo

• In order to expose <service>.enabled in the root app to allow override - <service>.enabled must be present in apps chart values.yaml (Not currently enforced)
• The current value of the parameter (including override) can be read using argocd app get <ns>/<app> -o yaml
• Using parameter means that the sub app always shows <service>.enabled as having been overridden

[gilesknap]

I'm still struggling with this a little - not sure of all of the implications. First I don't think that your approach needs to enforce 'enabled' flag as you can use the tertiary operator to turn 'not set' into the default 'true' .

There are too many variables to assess here for me to choose from:

• do we separate out ec_services and leave others to fend for themselves
• is deletion of the whole app acceptable for stopping it
• should we even allow overrides or just do everything in the repo
• if we allow both overrides and permanent stoppage:
  • should this be a separate flag (enabled vs removed for example)
  • how do we show in ec the difference (or even explain it to users)
  • should permanent stoppage be controlled at both root app and child app level (if so is that not confusing?) - reason to do this is DAQ want to not need to touch the deployment repo
  • likewise for overrides
• should we let ec write to the deployment repo for us so its easy and less error prone
• all of these questions should also be applied to DAQ requirements

[marcelldls]

@gilesknap to clarify - if you dont have enabled in your values then they do not show in the rootapp parameters. Adding a default doesn't solve this

[gilesknap]

All good