netboot
netboot copied to clipboard
danderson
Consider supporting an optional builtin full DHCP server
Pixiecore currently plays nice with existing DHCP servers, which is great... but that means you have to do more work if you don't have an existing DHCP server, e.g. when booting a machine over an ad-hoc crossover cable connected to your laptop.
I'm a bit wary of implementing a full DHCP server, because it gets horribly complicated horribly quickly... But if we define very clear rules of engagement (basically, minimal address management, and no options beyond router+DNS), I think we can make it work.
It would be awesome to have a bare bones dhcp server that can call out to a http api. I'm trying to solve the problem of wanting to have fixed ip addresses but still have them allocated automatically. If the dhcp server would call an http api with mac address I could write a really simple http server that asks a database for next available ip. Maybe it's a good idea to split the dhcp server out to a separate program.
I would LOVE to have this. Actually I have it, but written in python like 10 years ago. If Pixiecore would have this feature I could finally ditch my old code.
We need IPAM solutions for all this cloud native stuff anyway these days. Having a simple stupid dhcp <-> HTTP bridge seems to be the sole missing link to re-use the same central IPAM solution for kubernetes (CNI), docker (CNM), vms and bare metal (DHCP).
Maybe could get some inspiration from etcdhcp for the implementation. It seems it would be relatively straight forward for an experienced go programmer (which I am unfortunately not :-(). But the responsibility for allocating IPs would have to be with the http service.
Yeah, I've slowly come around to this, because I'd like this feature as well.
At some point, when I have some free time, I'll do a fairly large refactor of this repository to make this happen. I can't promise when.
Nope. This project is effectively abandonware. If it's useful, great. Maybe at some point I'll hack on it some more. But don't expect significant changes any time soon.
I understand. As long as you’re still open to pull requests that make sense that value to the core utility of this project that would be awesome!
On Thu, 28 Nov 2019 at 13:59, Dave Anderson [email protected] wrote:
Nope. This project is effectively abandonware. If it's useful, great. Maybe at some point I'll hack on it some more. But don't expect significant changes any time soon.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/danderson/netboot/issues/3?email_source=notifications&email_token=AAJ276QM4SXQH575VC6CAHLQV4627A5CNFSM4CNPHUX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLLXJQ#issuecomment-559332262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ276TW7N5PGEOXPPBXKQLQV4627ANCNFSM4CNPHUXQ .
--
James Mills / prologic
E: [email protected] W: prologic.shortcircuit.net.au
@danderson We expect this feature very much, we are assigning IP addresses via static linux kernel cmdl args so far, so only if we can provide the IPs via DHCP, that'll be more wonderful!
And we have a pain that the booting process can timeout at times, I suspect that's bcoz the kernel wants to collect some entropy from the nic during some booting steps, but no traffic could feed it under the static IP setup, so the DHCP traffic after preliminary boot seems very hopeful to be a relief.
Currently a typical machine we have can boot successfully 1 time out of 7~8 reboot attempts, which is still annoying even we don't reboot machines that often.
