Add retries to autoboot in ipxe script:

[jacobweinstock]

Description

This gives the autoboot (in the embedded script) a chance to overcome transient network issues or similiar.

Why is this needed

Fixes: #

How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

[codecov]

Codecov Report

Merging #87 (ded010a) into main (6eefab8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #87   +/-   ##
=======================================
  Coverage   97.25%   97.25%           
=======================================
  Files           5        5           
  Lines         437      437           
=======================================
  Hits          425      425           
  Misses          8        8           
  Partials        4        4           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jacobweinstock]

Pending a basic test from @nshalman , thanks Nahum!

[nshalman]

It's actually not behaving as expected for me. I'll see if I can figure out why.

[nshalman]

should this be iseq ${attempt} 5 && goto error-with-autoboot

[jacobweinstock]

ah, yes! good catch. will update

[jacobweinstock]

updated

[nshalman]

Didn't work when tested as written. comment with a possible fix.

[nshalman]

The more I think about this, the less I like the automated retries, but I do like the offer of a shell after a failure.
In the situation where a machine ought to be booting from disk, but is accidentally booting from the network, 5 retries could burn a lot of boot time. An offer of a shell to an operator watching after failure on the other hand might be hugely helpful for debugging while being less intrusive.

Also, I've been unable to get the retry logic to work. :(

[jacobweinstock]

The more I think about this, the less I like the automated retries, but I do like the offer of a shell after a failure. In the situation where a machine ought to be booting from disk, but is accidentally booting from the network, 5 retries could burn a lot of boot time. An offer of a shell to an operator watching after failure on the other hand might be hugely helpful for debugging while being less intrusive.

Also, I've been unable to get the retry logic to work. :(

Agreed, i think this is part of the reason i had this on hold for a while. the trade-offs of retrying weren't sitting right with me.

[nshalman]

Agreed, i think this is part of the reason i had this on hold for a while. the trade-offs of retrying weren't sitting right with me.

I'm glad you never merged it as-is.

[nshalman]

I did test the following which did appear to behave as I would expect:

diff --git a/binary/script/embed.ipxe b/binary/script/embed.ipxe
index b2c582b..5c85080 100644
--- a/binary/script/embed.ipxe
+++ b/binary/script/embed.ipxe
@@ -25,7 +25,9 @@ echo Booting from net${idx}...
 autoboot net${idx}

 :autoboot
-autoboot
+autoboot ||
+prompt --key 0x02 --timeout 2000 autoboot failed. Press Ctrl-B for the iPXE command line... && shell
+exit

 :boot-with-vlan
 set idx:int32 0

So I think I'm a 👎 on both the idea and the implementation of the retry logic, but I would be open to the brief offer of a shell after failure.

[jacobweinstock]

closing, please see conversation above.