-
Notifications
You must be signed in to change notification settings - Fork 693
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
Review CRDs for next release #1141
Comments
See https://gist.github.com/charith-elastic/21840956cb553ff31942b2166eed4cce for reference documentation generated from the CRDs. Quick links: |
Proposed Changes
|
Nice findings, some feedback:
Is this because we are prepared to use it if there is a need?
I think the naming is pretty accurate - name is the name of the node set, nodeCount is the number of nodes in the set. I think going with nodeName would be inaccurate, and going with count could be confusing (count of what? sets? nodes? volume claim templates?). Btw, #1488 was filled to discuss whether name 'nodes' is not confusing on its own - I think having nodeSet.count, nodeSet.name would be more clear. |
I think I like
+1 to remove it.
That's a tough question we debated many times 😄 We always have mixed feelings around using Elasticsearch vocabulary vs. Kubernetes vocabulary. Since we are in the context of the Elasticsearch CRD, I tend to think we are in the Elasticsearch domain, so we should tend to use Elasticsearch wording. However things like
-1 on that one, this would be even more confusing, since that name isn't used as the Elasticsearch node name, but as a basis for this name. The ES node name ends up being the pod name, eg.
I don't think so, it's a setting that applies across all nodeSpecs.
Can we rely on something landing beta in Kubernetes 1.15? But we can probably implement the same mechanism ourself. I don't have strong feelings. |
Isn't For specifying the connection to Elasticsearch, it doesn't have to be a formal union type but something similar to how different types of volumes are defined in the pod spec might be more idiomatic. Maybe introducing a field named backend:
elasticsearch:
url: https://es.local or backend:
elasticsearchRef:
name: "es"
|
I think our previous discussions assumed the following invariants:
That leaves us with the backend thingy. Can we just remove the elasticsearch:
certificateAuthorities:
secretName: clusterInternalCaCertSecretName # could go into kibana.yml via config
url: https://main-es-http:9200/ # same kibana.yml via config attribute
auth:
secret:
name: 'main-es-elastic-user', # do we need to make this configurable or can this just be a convention/label based discovery?
key: 'elastic' |
Presumably the |
Yes, the question is whether we want to move to implicit discovery (via naming convention or labels) for the CA secret and the user secret to be able to get rid of this section. |
To summarize the conversation so far:
I will leave this issue open for a couple of more days and if there are no further comments, raise issues for the following actions:
|
See #1488 for the discussion around |
Summary of progress so far:
|
I think we have covered all the major changes we wanted to go into v1.0.0-beta1 so this issue can be closed. Please re-open if I have missed something. |
Let's review our current CRDs and remove any redundant attributes that are there for historic reasons only.
One candidate that comes to mind is the
featureFlags
attribute.The text was updated successfully, but these errors were encountered: