-
Notifications
You must be signed in to change notification settings - Fork 261
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
apiServerLoadBalancer.enabled
set to false loops infinitely with ClusterClass
#1729
Comments
maybe we have enabled from false=>true or true=> false caes (though very unlikely) as cluster created with LB or w/ LB seems should not allow to switch over |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
This feels like a bug in ClusterClass. These are 2 valid representations of the same state: apiServerLoadBalancer:
enabled: false apiServerLoadBalancer: {} You're going to hit this anywhere you specify the implicit zero value for a field with |
In general, it is bad to have two ways to express the same thing within an API, I would lean towards removing the omitempty and making the API more discoverable by doing so. What is the meaning of Why in cluster class are we trying to set this explicitly? I guess the default is that the load balance is enabled and we want to disable it in this case? I don't think ClusterClass can know the difference, I'm not necessarily sure the API server even knows the difference, because this is a json serialisation issue. |
/remove-lifecycle stale |
Surely this is a general issue, though. It implies you can never use omitempty anywhere, because anywhere it is omitted you have 2 different representations of the same state: one where it is omitted, and one where it is included with the zero value.
It is not a pointer, and has cluster-api-provider-openstack/api/v1alpha8/openstackcluster_types.go Lines 80 to 83 in e89ec9c
|
Kube API guidelines tell you to use pointers for optional fields. In this case, the zero value being a nil, is not common for people to write out explicitly in their yaml. I think that would normally get around the present issue. You have to be careful when writing clients to try not to adjust what's already been written. Moving towards server side apply, this becomes much easier as clients are expected only to send content for fields that they care about themselves.
Omitempty only works for pointers to structs, not structs themselves, there is no point having omitempty on this case, it does nothing. Make it a pointer if you want the omit to work. |
After offline discussion with @JoelSpeed about this, I think I understand a new API principal: I'd like this to be another v1beta1 cleanup: remove omitempty from all values which aren't struct pointers. Unfortunately this may mean turning some structs (back) into pointers if we want to ensure they're omitted, which I hate because Go makes struct pointers in large data structures a syntactic minefield1. Footnotes
|
If you do not have required fields or validations inside a struct that should be optional, but would fail if With a struct with only optional fields, setting |
/assign mdbooth |
I believe this was fixed in #1937 |
/kind bug
What steps did you take and what happened:
When using ClusterClass and not enabling
apiServerLoadBalancer
, if the clusterClass sets the following:This will then be 'reverted' back to
And by doing that, it keeps looping forever, I've got an environemnt where the OpenStackCluster resource is up to 3412256(!) generations so far.
Upon editing the CRD and adding a default to
false
, it shows up in the CRD and reconciles just fine.What did you expect to happen:
We shouldn't probably let it be set or avoid the
omitempty
to make sure this doesnt happen.cluster-api-provider-openstack/api/v1alpha7/types.go
Line 302 in 8c6db5d
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
git rev-parse HEAD
if manually built):kubectl version
):/etc/os-release
):The text was updated successfully, but these errors were encountered: