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

DAOS-16312 control: Always use --force for dmg system stop #15803

Closed
wants to merge 1 commit into from

Conversation

tanabarr
Copy link
Contributor

Whenever stopping an engine process from within the control-plane, use
SIGKILL rather than asking nicely (SIGTERM). This has been requested
to try to avoid situations that could result in dataloss.

A side effect of this change is that ds_mgmt_drpc_prep_shutdown() and
then ds_pool_disable_exclude() will not be called during a controlled
shutdown where dmg system stop is called without other arguments.

Allow-unstable-test: true
Features: control

Before requesting gatekeeper:

  • Two review approvals and any prior change requests have been resolved.
  • Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
  • Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
  • Commit messages follows the guidelines outlined here.
  • Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

  • You are the appropriate gatekeeper to be landing the patch.
  • The PR has 2 reviews by people familiar with the code, including appropriate owners.
  • Githooks were used. If not, request that user install them and check copyright dates.
  • Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
  • All builds have passed. Check non-required builds for any new compiler warnings.
  • Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
  • If applicable, the PR has addressed any potential version compatibility issues.
  • Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
  • Extra checks if forced landing is requested
    • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
    • No new NLT or valgrind warnings. Check the classic view.
    • Quick-build or Quick-functional is not used.
  • Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

Allow-unstable-test: true
Features: control
Signed-off-by: Tom Nabarro <[email protected]>
@tanabarr tanabarr requested review from a team as code owners January 28, 2025 17:26
Copy link

Errors are Unable to load ticket data
https://daosio.atlassian.net/browse/DAOS-16312

@tanabarr
Copy link
Contributor Author

CI run 2 started with allow unstable pragma set and P2 priority

@daosbuild1
Copy link
Collaborator

Test stage Functional on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15803/2/testReport/

@tanabarr
Copy link
Contributor Author

Not all hardware stages started in run 2, restart from stage hardware test -> run 3.

Copy link
Contributor

@kjacque kjacque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the simplicity. I guess the one question is whether we need the prepare stage at all anymore, if it's okay to just kill the engines.

If the intention is to bring back the original behavior someday soon, with this being a temporary hack to fix an urgent problem, I think this is the best approach.

However if this is going to be permanent, or as close to it as software gets, I think more major surgery is in order (I believe you had another PR taking that approach?). If that's the case, I think we should remove all of the obsolete clean shutdown code. If we need to reimplement in a year or two, then so be it--the parameters of the problem may have changed by then.

@tanabarr
Copy link
Contributor Author

tanabarr commented Feb 3, 2025

replaced by #15799

@tanabarr tanabarr closed this Feb 3, 2025
@tanabarr tanabarr deleted the tanabarr/control-stop-sigkill-2 branch February 3, 2025 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants