-
Notifications
You must be signed in to change notification settings - Fork 16
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
Remove unnecessary use of StoreState
for configs
#209
Remove unnecessary use of StoreState
for configs
#209
Conversation
Will check if manual tests are required, marking WIP |
These changes should not require a manual test since it almost did not touch the core logic in the charm. Marking it "ready to review" by removing "[WIP]". Feel free to let me know if you want to manually test the charm in some way. |
StoreState
for configsStoreState
for configs
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.
LGTM
Left comment on just a small typo
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.
Thanks, please add issue you reported in comment here or mention that comment in the issue.
Open an issue found in this PR: #215 |
In config changed event, we should not keep the configs in
StoreState
just for tracking the which config option is changed, because any change of config option will result in a re-render of the exporter config yaml. The condition is almost always truthy so the tracking mechanism is useless.Closes #176, closes #208