Add an option to do a safe config reload #5374
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When doing a config reload, test cases cannot assume that the DUT is available immediately after `config_reload` returns. Instead, they need to wait on `duthost.critical_services_fully_started` to be true. Therefore, in `config_reload` add an option `safe_reload` (defaults to False to preserve current behavior) that will block on this so that the function returns when the DUT is ready. In addition, have two test cases (for now; other test cases will be checked later) use safe reload so that the DUT is guaranteed to be ready when the function returns. Otherwise, if the setup for the next test case is running while the DUT is still bringing up the containers, then some check there could fail. Signed-off-by: Saikrishna Arcot <[email protected]>
|
This pull request fixes 1 alert when merging bd9e4aa into 0eef697 - view on LGTM.com fixed alerts:
|
6 tasks
yxieca
reviewed
Mar 23, 2022
yxieca
reviewed
Mar 23, 2022
…assert Signed-off-by: Saikrishna Arcot <[email protected]>
yxieca
previously approved these changes
Mar 23, 2022
|
This pull request fixes 1 alert when merging a7143de into 18b4579 - view on LGTM.com fixed alerts:
|
Signed-off-by: Saikrishna Arcot <[email protected]>
|
This pull request fixes 1 alert when merging 5f6485d into 18b4579 - view on LGTM.com fixed alerts:
|
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
yxieca
approved these changes
Apr 4, 2022
wangxin
pushed a commit
that referenced
this pull request
Apr 5, 2022
* Add an option to do a safe config reload When doing a config reload, test cases cannot assume that the DUT is available immediately after `config_reload` returns. Instead, they need to wait on `duthost.critical_services_fully_started` to be true. Therefore, in `config_reload` add an option `safe_reload` (defaults to False to preserve current behavior) that will block on this so that the function returns when the DUT is ready. In addition, have two test cases (for now; other test cases will be checked later) use safe reload so that the DUT is guaranteed to be ready when the function returns. Otherwise, if the setup for the next test case is running while the DUT is still bringing up the containers, then some check there could fail. Signed-off-by: Saikrishna Arcot <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Saikrishna Arcot [email protected]
Description of PR
Summary:
When doing a config reload, test cases cannot assume that the DUT is
available immediately after
config_reloadreturns. Instead, they needto wait on
duthost.critical_services_fully_startedto be true.Therefore, in
config_reloadadd an optionsafe_reload(defaults toFalse to preserve current behavior) that will block on this so that the
function returns when the DUT is ready. In addition, have two test
cases (for now; other test cases will be checked later) use safe reload
so that the DUT is guaranteed to be ready when the function returns.
Otherwise, if the setup for the next test case is running while the
DUT is still bringing up the containers, then some check there could
fail.
Type of change
Back port request
Approach
What is the motivation for this PR?
How did you do it?
How did you verify/test it?
Locally ran t0-part1 KVM test, and it succeeded, which suggests that at least nothing broke because of this change.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation