-
Notifications
You must be signed in to change notification settings - Fork 727
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
Clean references to pod.Pod
following PodWithConfig introduction
#560
Labels
justdoit
Continuous improvement not related to a specific feature
Comments
sebgl
added a commit
that referenced
this issue
Mar 27, 2019
Propagate Elasticsearch configuration (elassticsearch.yml) through a secret volume mount, instead of using environment variables. Worth mentioning: Config format: I chose to keep things simple with the config: we only support a "flat" configuration. No hierarchical yaml, just my.inline.key: my value. Runtime info: we need the node name (based on the pod name) and the node IP (pod IP) in the config file, but these are only available once the pod is started. In order to do so, the config references an environment variable that will be injected by k8s itself. Changes computation: we now need to pass around the pod and its configuration while computing changes, instead of passing only the pod. This is done through a PodWithConfig struct. It does make the code less readable from time to time where it was using just a pod before: pod.Pod.Name. I'd like to avoid this big bang refactoring in this PR. I created this follow-up issue: #560. Creation order: We create the secret just before creating the pod, otherwise the pod would not start directly since the secret may not exist yet. Because the secret is created before the pod, we cannot set the pod as secret owner for automatic garbage collection of the secret when the pod is deleted. We manually delete the secret after pod deletion, but this PR also introduces a way to garbage-collect secrets that are not associated to any pod. Edge-case if no secret: we now consider a pod and its configuration in many cases. What should we do if a pod exists without a configuration secret? There are some "normal" cases (stale cache) that are worth ignoring. Otherwise (eg. the user manually deleted the secret), we mark the pod to be deleted as well. Comparison files: I split comparison.go into multiple files, in their own comparison package. It started to become quite big. * Split env settings from config settings * Compute the quorum from the node type label instead of the env * Introduce the FlatConfig type and its serializing functions to support a basic flat config * Introduce a secret volume for the configuration * Setup the default ES configuration * Split the comparison file into multiple files * Compare configs when comparing pods * Manipulate PodWithConfig instead of Pod * Propagate changes from using PodWithConfig instead of Pod in the codebase * Reconcile and mount config secret volume * Garbage-collect orphaned config secrets * Handle edge-case where a pod could exist without a config secret * Setup v7 initial master nodes in the config * Add license headers * Fix go fmt by using keyed fields in composite literal * Rename DeleteOrphanedResources to DeleteOrphanedSecrets * Improve FlatConfig.Sorted by using sort.SliceStable * Use sort.Slice instead of sort.SliceStable * Fix formatting * Remove commented useless function * Remove tainted pod comparison that we don't use anymore * Inject config secret volume and volume mount at the same time * Formatting fixes
Closing as this will be entirely removed with #1173. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #559, we introduce a
PodWithConfig
to move pod AND Config around, mostly in themutation
package.This does make the code not very friendly from time to time, with references to
pod.Pod
.We should probably fix these to something like
esnode.Pod
. Maybe renamePodWithConfig
toESNode
?The text was updated successfully, but these errors were encountered: