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.
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
YDBOPS-10613 Dynconfigs #62
base: main
Are you sure you want to change the base?
YDBOPS-10613 Dynconfigs #62
Changes from 8 commits
ddf842f
40ac992
49a3e08
6c94806
19d5474
216f617
41b0151
568a24f
a31e4c4
4962326
744b9c2
101028a
e1c98e0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's time to introduce the concept of playbook feature flags. I don't think we'd want to keep this setting around long-term: it's more like to test this new approach, make it default at some point and then deprecate the current approach. So it could be like this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's good idea for single roles, but we might have problems in our structure
playbook1 (feature_flag: feature1, feature3) -> role1 (feature_flag: feature1)
playbook1 (feature_flag: feature1, feature3) -> role2 (feature_flag: feature1, feature2)
in this case role2 will lost feature2 default value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's drop this setting because it'd limit the evolution of how all this is implemented under the hood. For instance, you don't really need a template here, you could just have the same object constructed in memory and then serialized to yaml. Otherwise, LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's designed to have possibility to adjust dynamic config for user needs until we have possibility to change all setting by ansible. Right not we do not provide a way to define labels or other requirements for dynamic nodes. IMHO it will be required by users for there production needs. That's why I think we must let them define their own config.