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

rebuild runner needs to read error messages from osd.py(runner) #1746

Open
jschmid1 opened this issue Sep 16, 2019 · 2 comments
Open

rebuild runner needs to read error messages from osd.py(runner) #1746

jschmid1 opened this issue Sep 16, 2019 · 2 comments
Assignees

Comments

@jschmid1
Copy link
Contributor

When running a salt-run rebuild.node operation which fails before unmounting the drive but after zapping it we have stale data from osd.list(minion module).

The osd.remove func will raise an Exception [OSDNotFound] that needs to be handled by this function.

Otherwise the rebuild runner just exits with:

[ERROR   ] Failed to remove OSD(s)... skipping data1
The following minions were skipped:
data1

Resolve any issues and run
 salt-run rebuild.nodes data1

I also noted that the rebuild runner in master is not the same as in SES6. That needs to be forwardported eventually.

@swiftgist
Copy link
Contributor

Shouldn't the try...except get caught in osd.remove since exceptions do not propagate across runners? Also, the osd.remove module is user facing and should give a reasonable return error independent of rebuild.node.

The _check_return is a summary of all the operations for a minion. Errors for a specific osd should come from osd.remove.

@jschmid1
Copy link
Contributor Author

Shouldn't the try...except get caught in osd.remove since exceptions do not propagate across runners? Also, the osd.remove module is user facing and should give a reasonable return error independent of rebuild.node.

Right, and I'm inclined to rework that..

The _check_return is a summary of all the operations for a minion. Errors for a specific osd should come from osd.remove.

It still needs context, I think the discussion we'll have about module return types for deepsea-next will have some influence on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants