-
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
[dhcp_relay] Disable dhcp_relay for ToRRouter switches type by the feature manager #7789
[dhcp_relay] Disable dhcp_relay for ToRRouter switches type by the feature manager #7789
Conversation
@dgsudharsan i am unable to assign you as a reviewer but appreciate if you can review and add comments. |
@liat-grozovik he did the internal review and approve it :) |
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 beside of the small comment which is mostly documentation of a so called WA
@@ -793,6 +793,12 @@ class HostConfigDaemon: | |||
syslog.syslog(syslog.LOG_WARNING, "Enable state of feature '{}' is None".format(feature_name)) | |||
continue | |||
|
|||
# dhcp_relay WA for production issue |
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.
what do you mean by WA? to ensure upgrade and backwards compatibility?
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.
MSFT have a production issue, they want only ToRRouter switches to enable dhcp relay service.
The previous approach was to disable the feature by not hooking dhcp packets, the new approach allow the user to enable it if it is configured to do so but still address the MSFT requirement to enable it by default only for ToRRouter.
If it is not a ToRRouter the user will have to override the configuration to enable it.
lgtm, did you test if rule gets added if the feature is enabled at a later stage? @dgsudharsan to review |
@prsunny Yes, for ToRRouter it will be enabled by default, for other types it will be disabled by default. |
@prsunny is it ok to merge? |
# dhcp_relay WA for production issue | ||
if feature_name == 'dhcp_relay': | ||
device_metadata = self.config_db.get_table('DEVICE_METADATA') | ||
if not (device_metadata and device_metadata['localhost'] and device_metadata['localhost']['type'] and device_metadata['localhost']['type'] != "ToRRouter"): |
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.
Please move this to state field in the init_cfg.json similar to mux
feature in the test cases.
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 tried to do so on init_cfg.json but this is not possible since this file is used on build stage and the value of "device_metadata['localhost']['type']" is not exist, so the approach here is to disable dhcp_relay by default.
hostcfgd will check on runtime if this is a ToRRouter switch and enable it accordingly.
If not, it will be disabled as desired, but if the user explicitly request to enable it, this will be accepted as well.
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.
The content of the state will be evaluated when loading the init_cfg.j2 for the first time. Also, the build J2 template will not render contents inside append
call. Something like the following:
{% do features.append(("dhcp_relay", "{% if 'type' in DEVICE_METADATA['localhost'] and DEVICE_METADATA['localhost']['type'] == 'ToRRouter' %}enabled{% else %}disabled{% endif %}", false, "enabled")) %}
Then we can remove the change in hostcfgd
all together.
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.
@tahmed-dev can you please check the changes now?
"has_timer": "False", | ||
"high_mem_alert": "disabled", | ||
"set_owner": "local", | ||
"state": "{% if 'subtype' in DEVICE_METADATA['localhost'] and DEVICE_METADATA['localhost']['subtype'] == 'DualToR' %}enabled{% else %}always_disabled{% endif %}" |
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.
Here is example of mux
feature.
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.
Since the dhcp_relay is disabled by default from init_cfg.json there is no reason to add this condition, it will be always disabled.
The UT should check if ToRRouter switched to 'enabled' state by hostcfgd, and if a non ToRRouter switch, which a user manually enabled, will stay enabled.
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.
The point is to move the code from hostcfg
to init_cfg.json.j2
@shlomibitton please help to resolve conflicts due to recent changes in hostcfgd. |
232bb83
@liat-grozovik resolved the conflicts |
Enable dhcp_relay trap from COPP manager by default. If the user want to enable the feature for non ToRRouter switches, manual enablement is required. This is to keep the current approach for MSFT production issue with dhcp relay for non ToRRouter switched and allow the user to decide if to use it or not. Change default values for 'dhcp_relay' on test cases to fit the change on 'init_cfg.json.j2'
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
"has_timer": "False", | ||
"high_mem_alert": "disabled", | ||
"set_owner": "kube", | ||
"state": "{% if not (DEVICE_METADATA is defined and DEVICE_METADATA['localhost'] is defined and DEVICE_METADATA['localhost']['type'] is defined and DEVICE_METADATA['localhost']['type'] != 'ToRRouter') %}enabled{% else %}disabled{% endif %}" |
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.
why use -ve logic? curious.
…ature manager (#7789) - Why I did it Currently dhcp packets are disabled by the COPP manager for non ToRRouter type switches. Even if the feature is enabled, DHCP packets wont hook to the CPU since the COPP manager will not trap this packets. This change is to disable dhcp_relay by default for non ToRRouter switches from init_cfg.json. With this approach, if the user want to enable the feature for non ToRRouter switches, manual enablement is required by the 'feature' configuration. This is to keep the current approach for MSFT production issue with dhcp relay for non ToRRouter switched and allow the user to decide if to use it or not. - How I did it Configure dhcp_relay 'disabled' by default on init_cfg.json for non ToRRouter switches. Remove the exclusion of dhcp packets on copp_cfg.json - How to verify it Enable dhcp_relay feature on a non ToRRouter switch. Unit-tests modified so the default values on mocked CONFIG DB in 'test_vectors.py' for dhcp_relay will be 'disabled'. This is by the change for 'init_cfg.json.j2'. For ToRRouter the state will change from 'disabled' to 'enabled'. Another test case added for a 'ToR' switch type, this is to test the state is 'enabled' if the user configured it to be so.
…ature manager (sonic-net#7789) - Why I did it Currently dhcp packets are disabled by the COPP manager for non ToRRouter type switches. Even if the feature is enabled, DHCP packets wont hook to the CPU since the COPP manager will not trap this packets. This change is to disable dhcp_relay by default for non ToRRouter switches from init_cfg.json. With this approach, if the user want to enable the feature for non ToRRouter switches, manual enablement is required by the 'feature' configuration. This is to keep the current approach for MSFT production issue with dhcp relay for non ToRRouter switched and allow the user to decide if to use it or not. - How I did it Configure dhcp_relay 'disabled' by default on init_cfg.json for non ToRRouter switches. Remove the exclusion of dhcp packets on copp_cfg.json - How to verify it Enable dhcp_relay feature on a non ToRRouter switch. Unit-tests modified so the default values on mocked CONFIG DB in 'test_vectors.py' for dhcp_relay will be 'disabled'. This is by the change for 'init_cfg.json.j2'. For ToRRouter the state will change from 'disabled' to 'enabled'. Another test case added for a 'ToR' switch type, this is to test the state is 'enabled' if the user configured it to be so.
Signed-off-by: Shlomi Bitton [email protected]
Why I did it
Currently dhcp packets are disabled by the COPP manager for non ToRRouter type switches.
Even if the feature is enabled, DHCP packets wont hook to the CPU since the COPP manager will not trap this packets.
This change is to disable dhcp_relay by default for non ToRRouter switches from init_cfg.json.
With this approach, if the user want to enable the feature for non ToRRouter switches, manual enablement is required by the 'feature' configuration.
This is to keep the current approach for MSFT production issue with dhcp relay for non ToRRouter switched and allow the user to decide if to use it or not.
How I did it
Configure dhcp_relay 'disabled' by default on init_cfg.json for non ToRRouter switches.
Remove the exclusion of dhcp packets on copp_cfg.json
How to verify it
This is by the change for 'init_cfg.json.j2'.
For ToRRouter the state will change from 'disabled' to 'enabled'.
Another test case added for a 'ToR' switch type, this is to test the state is 'enabled' if the user configured it to be so.
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)