Five minute delay DHCP'ing isolated nics
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Ben Nemec |
Bug Description
A new variation on https:/
This time it looks like it's the network systemd target that it taking 5 minutes. Because we set ONBOOT=yes in the nic config files the network target (which runs after the dhcp-all-interfaces services) tries to DHCP the isolated nics again and fails just like dhcp-all-interfaces did. However, because we set the timeout in the dhcp-all-interfaces service file the network target still waits for 5 full minutes before allowing boot to continue.
Note that as before, this is costing us a non-trivial amount of time in both CI and real net-iso deployments. I've definitely seen this when booting the overcloud-full image, but if it's like before then we're losing 5 minutes every time the IPA ramdisk boots too which means this would cost us 15 minutes per nonha deployment (5 for introspection, 5 for deploy, 5 for image boot).
I was hoping that since we add explicit service files for all the interfaces then maybe we wouldn't need ONBOOT, but it appears that the udev rule doesn't get applied on reboot so that is breaking networking in my tests. I need to investigate further with an image that I can login to if networking breaks.
Changed in tripleo: | |
milestone: | none → ocata-3 |
tags: | added: networking |
Changed in tripleo: | |
status: | Fix Committed → Fix Released |
On configuration (in t-h-t) could we update the configured nics accordingly then? Perhaps changing the ONBOOT setting during configuration time so that reboot is happy.