Support specifying control plane firewall rules when creating or updating DOKS clusters #696
Conversation
…trol-plane-firewall-rules-in-godo-and-doctl' into CON-10347-support-scecifying-control-plane-firewall-rules-in-godo-and-doctl
…irewall-rules-in-godo-and-doctl
| MaintenancePolicy *KubernetesMaintenancePolicy `json:"maintenance_policy,omitempty"` | ||
| AutoUpgrade *bool `json:"auto_upgrade,omitempty"` | ||
| SurgeUpgrade bool `json:"surge_upgrade,omitempty"` | ||
| ControlPlanePermission *KubernetesControlPlanePermission `json:"control_plane_permission,omitempty"` |
There was a problem hiding this comment.
Sanity check: will omitempty semantics combined with the KubernetesControlPlanePermission type not being pointerized work for our case? That is, will be see the desired behavior / serialization when the field is omitted for a given cluster configuration (firewall disabled vs enabled)?
Genuinely asking because this part of the Go JSON library is always a bit scary, and mistakes can be very hard to correct once the API is in use.
There was a problem hiding this comment.
Hi Timo, this is fine since I had been using my godo fork using this new struct for cluster that don't use control plane permission and e2e tests for clusters that use the feature. Also, we do have some logic if the field is not provided it won't be considered for storing or updating the record.
There was a problem hiding this comment.
Since Enabled takes a pointer and does not use omitempty, you should get the behavior (I'm assuming) you want.
Enabled *bool `json:"enabled"`
Add the new control plane permission property for creating or updating control plane firewalled clusters. By default, the zero value is
nilwhich won't break existing doks godo users since they won't be using this new feature.