Update StatefulSets on environment variable change #200
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@romain-bellanger We have a similar PR from @jryb for the same issue. Here is the link to the PR- #199 :) |
|
Closed as duplicated of #199 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This piece of code was actually added by @kashok-splunk in PR #120 (diff link), but removed in PR #145 (diff link) because it was not required anymore for its initial purpose, according to the PR comments.
However this also brought significant improvements for application load as described in issue #126. Thanks to this change, it was not required anymore to delete StatefulSets manually to trigger app deployments after updating the
defaultsUrlproperty of ClusterMaster or SearchHeadCluster CRDs, as the change ofSPLUNK_DEFAULTS_URLtriggered the update of the associated StatefulSets. We were able to put a continuous deployment pipeline in place thanks to this behavior, but it does not work anymore with the operator beta version 0.2.0.Possible impacts:
We noticed some impact on the monitoring-console pod, when the
defaultsUrlproperty is defined in some ClusterMaster or SearchHeadCluster resources. As the reconciliation of any Splunk custom resource calls the code building and applying the StatefulSet of the monitoring-console, and provides its own specs to build it, having a differentdefaultsUrlin some ClusterMaster and/or SearchHeadCluster resources seems to cause the monitoring-console StatefulSet to be constantly updated and switching its specs... This impact seems to be limited to the usage ofdefaultsUrl, as the other variables of the MC StatefulSet are not impacted by the custom resource spec.This code could be bypassed in the case of a monitoring console, but as the pod metadata is not passed to this method (labels not available), this would have to be done with a loop checking for environment variable
SPLUNK_ROLE, which would be a bit dirty. From our perspective this solution of monitoring-console inheriting its specs from a "random" resource has many other impacts and should be reviewed, as described in #189.