-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat(TPG>=5.44.2)!: add standard cluster support for insecureKubeletReadonlyPortEnabled
#2082
feat(TPG>=5.44.2)!: add standard cluster support for insecureKubeletReadonlyPortEnabled
#2082
Conversation
insecureKubeletReadonlyPortEnabled
insecureKubeletReadonlyPortEnabled
2faae5f
to
1c97a95
Compare
/gcbrun |
Thanks for triggering @apeabody |
I think this might have been a flaky run, re-triggered the test. |
/gcbrun |
Thanks, yeah, passed that time. Any other adjustments you all want? presumably this will have to wait for another major release? |
Not sure if there's anything special that needs to be done to support the situation where the default changes down the road. I think leaving the default |
/gcbrun |
Correct - This is a breaking change, so will need to wait till we start assembling the next major version. |
It's hard to predict, but as this is a field (and not a block), leaving as |
/gcbrun |
1 similar comment
/gcbrun |
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.
@apeabody I realized this probably needs to also be tested in a couple more spots (and probably should use "FALSE"
as the default, since even though "TRUE"
may be a safer bet, we probably don't want to encourage people to set that by putting it in examples) , and probably setup for autopilot clusters too? Does it make sense to use a single parameter to handle
node_pool_auto_config.kubelet_config.insecure_kubelet_readonly_port_enabled
for autopilot clusters (currently a bit stuck on how to handle that block)node_pool_defaults.node_config_defaults.insecure_kubelet_readonly_port_enabled
(I thinknode_pool_defaults.node_config_defaults
needs to have its beta gate removed as well?- node pool settings (
node_config.kubelet_config
) at the node-pool level
I guess maybe we need to differentiate between the setting for a given node pool vs. the autopilot or node_pool_defaults
cases, where there'd just be a parameter set at the top level, so maybe don't try to solve that problem as part of this PR?
Does it make sense to have the same parameter name (insecure_kubelet_readonly_port_enabled
) as a module variable and as a value within the node_pools
var as well?
I haven't looked into these specifically, but generally we want to retain the ability for a separate cluster vs nodepool configuration - same parameter name is fine. Looking into |
Ok, I may convert this to a draft, but just pushed up something for you to look at here. While it would be nice to have it be a true bool, I'm thinking match the upstream behavior of |
dbe36b1
to
0411c32
Compare
/gcbrun |
Co-authored-by: Andrew Peabody <[email protected]>
insecureKubeletReadonlyPortEnabled
insecureKubeletReadonlyPortEnabled
c4db48a
to
b6c5fa6
Compare
/gcbrun |
/gcbrun |
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.
Thanks for the contribution @wyardley!
@apeabody is the test failure now due to this setting / expectations, or another transient failure? |
node pool timed out, retriggered |
/gcbrun |
This adds support for
insecure_kubelet_readonly_port_enabled
, now that it's supported at the provider level.This will need either > 5.44.2 (cherrypicked update) or > 6.7.0, so will be a breaking change; happy to tweak the title and / or commit type as desired.
Fixes #2013