-
Notifications
You must be signed in to change notification settings - Fork 153
Remove deprecated proxy fields from Provider API #1190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| err := errors.New("specifying proxy with 'proxy' key in the referenced secret is deprecated, use spec.proxySecretRef with 'address' key instead. Support for the 'proxy' key is removed in v1") | ||
| log.FromContext(ctx).Error(err, "no longer supported.") | ||
| return nil, nil, err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone applies a manifest that still includes .spec.proxy, it will likely error because the field has been removed. However, using the deprecated proxy key in a Secret’s data won’t cause that kind of failure.
Given that, I’ve kept the error handling in place. Users will see the issue via kubectl describe, and operators will get a clear message in the logs.
If you think this is overkill or have a simpler approach, I’m all ears.
bc217dc to
59f2038
Compare
The spec.proxy field and 'proxy' key in secrets are no longer supported. These fields were deprecated in v2.7 with the introduction of spec.proxySecretRef as the recommended approach. Signed-off-by: cappyzawa <[email protected]>
59f2038 to
4a82d2c
Compare
|
Quick recap (mostly for future me since it's been a while 😅): Timeline
Why the revert? Next steps Note According to the official documentation, only http/https/socks5 schemes are officially supported for proxy configuration. |
Small correction: Making the validation stricter isn't suitable for a patch release (unless we're fixing a CVE, which was not the case), so we decided to revert the validation PR in |
ref: #1144 .
Note: The proxy URL parsing optimization mentioned in #1144 will be addressed in a separate follow-up PR.