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.

Sign up for GitHub

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

Jump to bottom

boots should not panic on bad hardware data #28

Closed
Ottovsky opened this issue May 13, 2020 · 3 comments
Closed

boots should not panic on bad hardware data #28

Ottovsky opened this issue May 13, 2020 · 3 comments
Assignees
@Cbkhare
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. size/S estimate of the amount of work to address the issue

Comments

@Ottovsky
Copy link

I made a mistake in my hardware data definition and I observed a fatal panic in the boots, which crashed it completely. I don't think it is a suitable behaviour, in my opinion it would be better to recover from panic and log error message, allowing boots to continue operating.
The panic was caused by the code in https://github.com/tinkerbell/boots/blob/master/job/job.go#L79 .
@Ottovsky Ottovsky mentioned this issue May 13, 2020
Closed
@nathangoulding nathangoulding added kind/feature Categorizes issue or PR as related to a new feature. good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. priority/backlog Higher priority than priority/awaiting-more-evidence. labels Jul 21, 2020
@nathangoulding
Copy link
Contributor

This would be good to address, i.e. returning an error instead of panicing.

@nathangoulding nathangoulding added the size/S estimate of the amount of work to address the issue label Jul 21, 2020
@Cbkhare
Copy link
Contributor

Cbkhare commented Aug 21, 2020 •
edited
Loading

@Ottovsky I tested your problem from on my vagrant setup. Did some regress testing with issue #61. My boot container was able to recover after the panic. Can you please test it once again at your end. If the problem persists then please share the steps to reproduce the issue.

@Cbkhare Cbkhare self-assigned this Aug 21, 2020
Cbkhare added a commit that referenced this issue Aug 24, 2020
@Cbkhare
fix for hardware data without metdata
d4d1b5b 
Signed-off-by: cbkhare <Chitrabasukhare89@gmail.com>

fix for hardware data without metdata #61 #28

Signed-off-by: cbkhare <Chitrabasukhare89@gmail.com>
@Ottovsky
Copy link
Author

Looks good now, closing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Cbkhare Cbkhare

Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. size/S estimate of the amount of work to address the issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nathangoulding @Cbkhare @Ottovsky