-
Notifications
You must be signed in to change notification settings - Fork 31
Cleaning up v1alpha1 API in preparation for a 'stable' cut #194
Comments
In CassandraCluster:
In ElasticsearchCluster:
I've planned for a while to allow the user to not have to specify all of the fields in this file, and instead have the pilot automatically inject config into the file (i.e. have the I'm not sure where best the tradeoff lies between overly complex ElasticsearchCluster manifests and the right level of customisability. /cc @cehoffman @wallrj |
Automatic merge from submit-queue. elasticsearch: Replace 'config' field with 'minimumMasters' **What this PR does / why we need it**: This PR alters the API surface for ElasticsearchCluster. It replaces the config field on node pools with a cluster wide minimum masters field. The official Elastic recommendation is to modify the majority of cluster settings through the cluster API, and without a specific request to have a method to specify *static* config, I think we're best to remove this field for now. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # Related to #194 **Release note**: ```release-note Remove 'config' field from node pools and replace with cluster-wide 'minimumMasters' field ```
In #194 (comment) @munnerz wrote:
Probably not. I've looked at GoCQL and its cluster discovery mechanism and I think the CQL loadbalancing service may not be necessary and may actually confuse the discovery process....since the loadbalancer IP address isn't one of the addresses advertised by the cluster nodes. See #232 In which case, we may not need the readiness probe either 🤔
I'm think the nodepool may be the mechanism by which we support multiple racks and datacentres. See #227 And perhaps you'd add another node pool if you want to change the size or class of the disks attached to nodes. Add a new pool with desired disks. Remove the pool with original disks.
Not yet. But hopefully soon. See #140 |
I think we should remove |
I'm pretty much in agreement at the moment. The only sysctl settings I think that should be allowed through are those in the safe/whitelist that kubelet knows how to apply through annotations on the pod. https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/#setting-sysctls-for-a-pod |
Before we close this, we should make sure we don't return 'null' as a field value anywhere, else clients could get confused. I've seen it at various points in our API, and for now I think we'll need to run a manual check. Perhaps some kind of basic checking of default values for all fields results in a resource returned with no |
We want to cut a 'stable' v1alpha1 API that can be depended upon, and begin working in the v1alpha2 API.
Before we do this, in the brief remaining window where we can perform breaking API changes, we should make our 'last' API changes to v1alpha1.
I'd like to call a review on all of our resources:
(taken from: https://github.com/jetstack/navigator/blob/afed2beb6a1f9638fb2b2ffe9fdad9b73704717c/pkg/apis/navigator/v1alpha1/types.go)
The text was updated successfully, but these errors were encountered: