DHCP-less/inband Bootz spec changes#316
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a DHCP-less (inband) operating mode for Bootz, updating the documentation to include new entry points, cleanup procedures, and a standardized CLI specification across Unary Bootz and BootstrapStream (v0.6 and v1.0) protocols. Review feedback highlights a numbering error in the Unary Bootz section and suggests consistent formatting for the cleanup steps across all protocol versions.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
gmacf
changed the title
|
|
||
| #### DHCP-less (inband) | ||
|
|
||
| In environments where DHCP is not available or out-of-band (OOB) management |
There was a problem hiding this comment.
If device need to do dhcp-less bootz if local config for dhcp-less is available on devcie, do we need the default option on device to set as "dhcp-less" option.
as per above definition the default behaviour is to use the dhcp based discovery.
- what should be the criteria for fall back to dhcp-less.
- "local configuration" (specific to dhcp-less config), is this the trigger tigger for using "dhcp-less", if config present always use "dhcp-less".
(or do the devcie need to run regular dhcp based discovery and if no success (max try), look for dhcp-less method)
Is this case(dhcp-less) applied only manually initiation, is this applied to below cases, if applied what will be the behaviour for following cases.
- factory reset
only dhcp based discovery is possible
- reload (both can be active)
assumed, in this case device will look for local persistent cfg, if present perform dhcp-less
- reimage
make sure persistent config is not removed
assume device should, use dhcp-less if local config present - manual initiate
devcie should follow the initiate commad, if no specific option given, use dhcp-less lookup as first method.
| 1. A network operator manually configures the device with a local | ||
| configuration that gives it reachability to the Bootz server. This | ||
| includes static routing, interface configuration and local admin | ||
| credentials. |
There was a problem hiding this comment.
If local admin credentials are already configured.
- what will be the exit criteria for bootz work, as it is going to run in backgroud till success.
- bootz work flow involves reload/reimage and the exit criteria is the detection of configuration, If devcie is already contains configuration bootz will assume device is already provisioned, otherwise will attempt bootz starting with dhcp discovery
(with new case will be one of dhcp discovery or dhcp-less).
If we have admin creds on device before starting bootz, if bootz workflow reloads the devcie, bootz run will go in background, even if the user logs in bootz will be still running in background, need explicit terminate from user.
| credentials. | ||
| 2. A network operator triggers DHCP-less Bootz via CLI, providing the | ||
| Bootz Server URI and Source Interface. These are saved to a | ||
| persistent parameters file on disk to survive reboots. |
There was a problem hiding this comment.
What will the scope and life time of this persistent data.
- If this data is present on device, every time when device gets a reload/reiame (manual), there is a risk of device starting dhcp-less workflow, as there is no other exit criteria (user cred is not an exit criteria now).
| 4. If the DHCP-less Bootz process fails at any point, the device MUST | ||
| revert back to the operator-provided local configuration and attempt | ||
| to connect to the Bootz server again. The device MUST remain in this | ||
| recovery loop until either: |
There was a problem hiding this comment.
on failure:
- device should fall back to initial configuration.
assume that device need to retry bootz again (dhcp-less mode).
| recovery loop until either: | ||
| 1. Bootz completes successfully | ||
| 2. The operator manually resets the device to standard DHCP mode | ||
| via the CLI, at which point Option A takes effect. |
There was a problem hiding this comment.
on this mode change(removing cfg/dhcp-less persistent config) do we need to exit current instance of bootz ?
- do we need autostart of bootz on mode chnage,
(or wait for user to trigger the again using manual reload/initiate command ?)
3 participants
No description provided.