Skip to content
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

Merged
merged 2 commits into from
Jul 8, 2021
Merged

[dhcp_relay] Disable dhcp_relay for ToRRouter switches type by the feature manager #7789

merged 2 commits into from
Jul 8, 2021

Conversation

shlomibitton
Copy link
Contributor

@shlomibitton shlomibitton commented Jun 3, 2021

Signed-off-by: Shlomi Bitton shlomibi@nvidia.com

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.

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

@liat-grozovik
Copy link
Collaborator

@dgsudharsan i am unable to assign you as a reviewer but appreciate if you can review and add comments.

@shlomibitton
Copy link
Contributor Author

@liat-grozovik he did the internal review and approve it :)

Copy link
Collaborator

@liat-grozovik liat-grozovik left a 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
Copy link
Collaborator

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?

Copy link
Contributor Author

@shlomibitton shlomibitton Jun 13, 2021

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.

@prsunny
Copy link
Contributor

prsunny commented Jun 17, 2021

lgtm, did you test if rule gets added if the feature is enabled at a later stage? @dgsudharsan to review

@shlomibitton
Copy link
Contributor Author

shlomibitton commented Jun 21, 2021

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.
But, if the user enabled the feature with a non ToRRouter switch it will stay enabled.
I added a UT cases to verify it as well.

liat-grozovik
liat-grozovik previously approved these changes Jun 23, 2021
dgsudharsan
dgsudharsan previously approved these changes Jun 23, 2021
@liat-grozovik
Copy link
Collaborator

@prsunny is it ok to merge?

files/image_config/copp/copp_cfg.j2 Show resolved Hide resolved
# 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"):
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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 %}"
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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

@liat-grozovik
Copy link
Collaborator

@shlomibitton please help to resolve conflicts due to recent changes in hostcfgd.

@shlomibitton
Copy link
Contributor Author

@shlomibitton please help to resolve conflicts due to recent changes in hostcfgd.

@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'
@liat-grozovik
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

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 %}"
Copy link
Contributor

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.

@liat-grozovik liat-grozovik merged commit 776a446 into sonic-net:master Jul 8, 2021
@shlomibitton shlomibitton deleted the disable_dhcp_default branch July 20, 2021 08:52
judyjoseph pushed a commit that referenced this pull request Aug 4, 2021
…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.
carl-nokia pushed a commit to carl-nokia/sonic-buildimage that referenced this pull request Aug 7, 2021
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants