-
Notifications
You must be signed in to change notification settings - Fork 92
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
Fix: ra: Prevent to add unknown operation (bsc#1236442) #1679
base: master
Are you sure you want to change the base?
Fix: ra: Prevent to add unknown operation (bsc#1236442) #1679
Conversation
liangxin1300
commented
Jan 27, 2025
- When adding unknown operation, sanity check should give an error instead of a warning
- And sanity check will return a big number to indicate this is a fatal error, so that the commit process will be aborted
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
5d54ee1
to
b7c15db
Compare
crmsh/ui_configure.py
Outdated
@@ -744,6 +744,8 @@ def _verify(self, set_obj_semantic, set_obj_all): | |||
rc1 = set_obj_all.verify() | |||
if config.core.check_frequency != "never": | |||
rc2 = set_obj_semantic.semantic_check(set_obj_all) | |||
if rc2 >= constants.SANITY_FATAL_RC: | |||
cib_factory.reset() |
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 reset()
should not be called here.
_verify()
is also called fromdo_verify()
. This subcommand should not have a side effect.- Even when called from
_commit()
, it is enough to abort the commit, so that users will have a chance to modify their config instead of losing all the changes.
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.
Changed as raising utils.TerminateSubCommand
- non-interactive case:
alp-1:~ # crm configure primitive stateful-1 ocf:pacemaker:Stateful op monitor_Slave interval=10s op monitor_Master interval=5s
WARNING: (unpack_config) warning: Blind faith: not fencing unseen nodes
ERROR: Action 'monitor_Slave' not found in Resource Agent meta-data
ERROR: Action 'monitor_Master' not found in Resource Agent meta-data
alp-1:~ # crm configure show stateful-1
ERROR: object stateful-1 does not exist
- interactive case:
alp-1:~ # crm
crm(live/alp-1)# configure
crm(live/alp-1)configure# primitive stateful-1 ocf:pacemaker:Stateful op monitor_Slave interval=10s op monitor_Master interval=5s
crm(live/alp-1)configure# primitive d2 Dummy
# terminate the commit, but the temp changes are still there
crm(live/alp-1)configure# commit
WARNING: (unpack_config) warning: Blind faith: not fencing unseen nodes
ERROR: Action 'monitor_Slave' not found in Resource Agent meta-data
ERROR: Action 'monitor_Master' not found in Resource Agent meta-data
crm(live/alp-1)configure# show stateful-1
primitive stateful-1 ocf:pacemaker:Stateful \
op monitor_Slave interval=10s \
op monitor_Master interval=5s
crm(live/alp-1)configure# show d2
primitive d2 Dummy
# verify will raise error, without side effect
crm(live/alp-1)configure# verify
WARNING: (unpack_config) warning: Blind faith: not fencing unseen nodes
ERROR: Action 'monitor_Slave' not found in Resource Agent meta-data
ERROR: Action 'monitor_Master' not found in Resource Agent meta-data
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.
Raising TerminateSubcommand looks like a hack. Why not just return False in _verify()
? Does this unknown operation verification has any difference with other verifications?
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.
Based on the current logic, if the function returns False, the changes can still be forcefully committed or committed after user confirmation by asking, "Do you still want to commit?"
Currently, some invalid configurations are allowed to be committed into CIB, such as missing a required parameter for an RA.
However, allowing unknown operations into CIB can lead to high CPU usage (see bsc#1236442), which is why an exception is raised in these cases.
Perhaps here we should have two different handling policies for fatal and non-fatal cases. Fatal cases must terminate the process, whereas non-fatal cases can be forcefully committed after user confirmation.
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.
So, it will be better to use different return values in _verify()
to represent fatal and non-fatal errors, and add some comments to note why this is a fatal error.
edc47e9
to
033a45c
Compare
- When adding unknown operation, sanity check should give an error instead of a warning - And sanity check will return a big number to indicate this is a fatal error, so that the commit process will be aborted
Avoid get empty options in else case
033a45c
to
eb8e9fc
Compare