-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[hostcfgd] check cached state instead of the next state #6067
Conversation
When checking if a feature is 'always_enabled', check the cached state to prevent new change to be accepted. Signed-off-by: Ying Xie <ying.xie@microsoft.com>
@yxieca I think we do not need this change this once we update sonic-util submodule which will bring change from this PR: sonic-net/sonic-utilities#1271 PR for submodule update: #6070 |
@abdosi I think we still need this change. I fixed 2 logic issues in this change and added a protection (reverting wrong change). I hope we never need to exercise the protection. But the 2 logic error fixes are necessary. @yxieca a) We update cache state first in update_all_feature_states. This make sure we get “always_enabled” Idea to use next ‘state’ (user provided value) to protect was based on assumption sonic-util has correct check. |
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.
extra protection, looks ok.
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. The change helps "always_enabled" to be maintain and not to be over-written in any case
as extra check over CLI command.
- Why I did it 'always_enabled' feature can still be disabled/enabled. - How I did it When checking if a feature is 'always_enabled', check the cached state to prevent new change to be accepted. Fix an issue where cache value is updated before all the check is done. Restore 'always_enabled' value in config db if someone wants to change. Signed-off-by: Ying Xie ying.xie@microsoft.com - How to verify it Without the fix, 'always_enabled' feature can be enabled or disabled without cli protection. With the protection, the change will be rejected properly.
- Why I did it
'always_enabled' feature can still be disabled/enabled.
- How I did it
When checking if a feature is 'always_enabled', check the cached state to prevent new change to be accepted.
Fix an issue where cache value is updated before all the check is done.
Restore 'always_enabled' value in config db if someone wants to change.
Signed-off-by: Ying Xie ying.xie@microsoft.com
- How to verify it
Without the change:
root@str2-dx010-acs-6:/home/admin# show feature status
Feature State AutoRestart
...
teamd always_enabled enabled
...
root@str2-dx010-acs-6:/home/admin# config feature state teamd disabled
root@str2-dx010-acs-6:/home/admin# show feature status
Feature State AutoRestart
...
teamd disabled enabled
...
With the fix:
root@str2-dx010-acs-6:/home/admin# config feature state teamd disabled
root@str2-dx010-acs-6:/home/admin# show feature status
Feature State AutoRestart
...
teamd always_enabled enabled
...