-
Notifications
You must be signed in to change notification settings - Fork 580
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
Forget modified attribute on config change #8739
Conversation
Before
After
|
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.
I think before changing this PR, we should have a discussion how we actually expect and want modified attributes to behave.
lib/icinga/icingaapplication.cpp
Outdated
ConfigWriter::EmitRaw(fp, "\tif (obj.get_attribute("); | ||
ConfigWriter::EmitString(fp, attr); | ||
ConfigWriter::EmitRaw(fp, ", &result) && Json.encode(Internal.serialize(result, 2 /* FAConfig */)) == "); |
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.
Given that obj.get_attribute(...)
will return false if the attribute does not exist in the original object (i.e. as read from the regular config files), this will lose modified attributes in this case.
Also, is JSON-encoding things really the best we can do to compare values?
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 say: "if the attribute does not exist in the original object anymore" – that’s this PR's intention
- Inside config files IMAO yes
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.
- That's not what the emitted code checks for.
obj
at that point corresponds to the object in the config. So if set a modified attributedoes_not_exist_in_config_file
using the API and then restart Icinga, you would lose that attribute as theget_attribute()
call returns false. - But this persists JSON across restarts and then uses string comparison later. Thus we could never again change something in the JSON serialization without risking losing modified attributes. If we would have done JsonEncode(): serialize integers w/o trailing .0 #8697 after this PR, if you had an modified attribute where the original value was an integer, the modified attribute would have been dropped (
"1.0" != "1"
, therefore the config would be considered as changed even though it wasn't).
This won't make it into 2.13, there are too many remaining issues. Another example: since this persists JSON to later use it in a string comparison, this would effectively prevent any future changes to the JSON encoder. Think of something like #8697 or #8748, with this PR merged, we couldn't do any of that anymore without risking to lose modified attributes. |
@cla-bot check |
…ersistModAttrHelper() as well refs #8717
4688077
to
206a0fa
Compare
Better?
|
Have we even agreed that this is the behavior we want? |
No, I've just asked whether the obvious issues you pointed out are gone. |
We don't want this, right? |
This PR is the one trying to remove modified attributes based on detecting changes in config files, isn't it? Then I'd say we close this, yes. In general, I'd treat modified attributes as API-based attribute overrides, meaning that if you set an attribute via the API, that takes precedence until you clear it via the API (which we don't provide a proper mechanism for at the moment). Detecting the intention to change an attribute via config files is hard to impossible, where it is an explicit action in the API. Consider the following example: you have an service that doesn't explicitly set So the approach of this PR will easily result in a mix of complex rules and strange edge-cases. On the other hand, API-set attribute wins until it's cleared via the API is a pretty simple and clear rule. |
fixes #8717
fixes #8709