Version local registry cert files#924
Merged
hardys merged 1 commit intoopenshift-metal3:masterfrom Feb 7, 2020
Merged
Conversation
We only want to generate these cert files when necessary, either on a new deployment of the registry or when the cert files change. The previous check for existence meant the latter case wasn't handled correctly. Even if we fixed that somehow, the md5 check later wasn't effective either because the directory is bind mounted into the container so we're essentially checking that the md5 of the file matches itself. To address these issues, I've added a version number to the cert and key files for the registry. If/when we make further changes to the cert configuration for the registry we just need to bump that version to force an update of the registry. The registry restart is also explicitly requested any time the certs are re-generated so we don't have to try to figure out which cert is in use. It's possible we could try to inspect the existing cert for differences with the desired cert, but that would be more complicated and I'm not sure it would be less error-prone than this approach.
|
Thanks for fixing this, it's something I missed in #902 I was thinking we'd inspect the existing certs, but this approach seems fine as an alternative - I'll test locally but lgtm! |
|
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1494/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We only want to generate these cert files when necessary, either on
a new deployment of the registry or when the cert files change.
The previous check for existence meant the latter case wasn't handled
correctly. Even if we fixed that somehow, the md5 check later wasn't
effective either because the directory is bind mounted into the
container so we're essentially checking that the md5 of the file
matches itself.
To address these issues, I've added a version number to the cert and
key files for the registry. If/when we make further changes to the
cert configuration for the registry we just need to bump that version
to force an update of the registry. The registry restart is also
explicitly requested any time the certs are re-generated so we don't
have to try to figure out which cert is in use.
It's possible we could try to inspect the existing cert for differences
with the desired cert, but that would be more complicated and I'm not
sure it would be less error-prone than this approach.