You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 7, 2021. It is now read-only.
While migrating gerrit for gluster, i realized that having a selfsigned certificate mode creation could be useful for testing. However, the current way to specifiy what certificate to use is not scalable, since we have to add 1 variable per method. We currently have 2 (freeipa and letsencrypt), and so I would like to propose the following:
deprecate the 2 parameters (ie, convert them to the new style, along a message)
replace by "use_https: freeipa" or "use_https: letsencrypt" (maybe add acme, just to be pedant).
This would permit to avoid corner cases like something turning the 2 parameters at the same time (which is likely gonna do something stupid). This would also permit to extend certificate handling more cleanly.
I would propose a 6 month period after which we remove the deprecation notice and where removal of the code is fair game.
The text was updated successfully, but these errors were encountered:
Seems fine. We should use this kind of settings more often when we know there are more than one useful method (for TLS, auth…), even if we do not implement more than one yet.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While migrating gerrit for gluster, i realized that having a selfsigned certificate mode creation could be useful for testing. However, the current way to specifiy what certificate to use is not scalable, since we have to add 1 variable per method. We currently have 2 (freeipa and letsencrypt), and so I would like to propose the following:
This would permit to avoid corner cases like something turning the 2 parameters at the same time (which is likely gonna do something stupid). This would also permit to extend certificate handling more cleanly.
I would propose a 6 month period after which we remove the deprecation notice and where removal of the code is fair game.
The text was updated successfully, but these errors were encountered: