Temporary hold on ops image id updates once in production

[DJAndries]

Once we're in production with P3A, we should probably put a hold on production image updates (image ids specified in the ops repo) for both the nitro-shim & star-randsrv unless absolutely critical, until brave/nitriding-daemon#10 is resolved.

[NullHypothesis]

That's a good idea. Alternatively (or in addition), we could configure flux to hold off on auto-updating the pods when it sees a new nitro-shim image in ECR. Then again, the nitro-shim doesn't change a lot anyway and if I understand correctly, changes to star-randsrv aren't going to get auto-deployed because star-randsrv's image is an argument to nitro-shim's startup script.

[rillian]

changes to star-randsrv aren't going to get auto-deployed

That was my understanding too. Both the run book and the code in the star-randsrv-ops repo specify an explicit image version, not just the latest build.

If we do deploy automatically to production, we should limit it to tagged releases or similar. Limiting merges to the default branch for for normal work is tedious.

[DJAndries]

Then again, the nitro-shim doesn't change a lot anyway and if I understand correctly, changes to star-randsrv aren't going to get auto-deployed because star-randsrv's image is an argument to nitro-shim's startup script.

That was my understanding too. Both the run book and the code in the star-randsrv-ops repo specify an explicit image version, not just the latest build

Right, just noticed this. will update title & description to refer to "image updates" instead, so we don't lose the key material for the current epoch in production

[rillian]

We haven't resolved the underlying cause, but we also haven't been able to run this in an enclave for a while, so I think we can expire this prohibition for now. Still an issue to be aware of with future deployments once aws/aws-nitro-enclaves-cli#550 is addressed.