Closed JimMadge closed 3 months ago
The main reason for this is because SRE config is the only place we expect/want a deployer to directly interact with the config file. dsh context add
and dsh shm deploy
both have command line arguments, but these are as minimal as we can make them. I'd prefer not to have two separate config files that we expect people to manage by hand and I'd also prefer not to go back to a single large config file with both SHM and SRE information in it.
Oh another thing I just thought of: we want to keep the SRE and SHM as independent as possible, so we don't end up back in the v4 situation where upgrading to the latest release is painful and involves updating all your existing SREs rather than just plugging updated SREs into your existing SHM.
It would be two extra mandatory command line arguments to dsh shm deploy
which is annoying.
I wouldn't encourage people to modify that by hand. Although, I suppose the Docker credentials are more likely to change than the subscription id etc..
I think what I find most odd is I can't see a situation where it is a feature to use different credentials for different SREs so it feels like it will more likely be a pain to write the same lines in every SRE config.
Different admins responsible for different SREs, each using their own DockerHub PAT?
I lean towards keeping it in the SRE. There's a lot of duplication between different SRE configs already so another couple of fields won't make much difference
The Docker Hub credentials are currently defined in SRE configuration. I think this is a bit odd because,