Cloud-init update renders secondary addresses to be incompatible with standard tools
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cloud-init |
Expired
|
Medium
|
Unassigned | ||
| curtin |
Confirmed
|
Medium
|
Unassigned | ||
| cloud-init (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
| resolvconf (Debian) |
Won't Fix
|
Unknown
|
|||
| resolvconf (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
The change of how cloud-init renders /etc/network/
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is empty:
Consider:
root@tester:~# cat /etc/network/
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:
root@tester:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet. The second definition of eth0 has no nameserver and therefore overrides the definition.
Related branches
- Scott Moser: Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 135 lines (+34/-30)2 files modifiedcloudinit/sources/helpers/digitalocean.py (+7/-11)
tests/unittests/test_datasource/test_digitalocean.py (+27/-19)
| description: | updated |
| Ryan Harper (raharper) wrote | #1 |
| Changed in cloud-init: | |
| status: | New → Incomplete |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #2 |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #3 |
| Changed in cloud-init: | |
| status: | Incomplete → New |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #4 |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #5 |
| Changed in cloud-init: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| affects: | cloud-init → cloud-init (Ubuntu) |
| Changed in cloud-init: | |
| status: | New → Confirmed |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #6 |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #7 |
| Ben Howard (darkmuggle-deactivatedaccount) wrote | #8 |
| summary: |
- 0.7.9-48-g1c795b9-0ubuntu1~16.04.1 with multiple eth0 definitions has no - resolvers + Cloud-init update renders secondary addresses ti be incompatible with + standard tools |
| description: | updated |
| Ben Howard (darkmuggle-deactivatedaccount) wrote Re: Cloud-init update renders secondary addresses ti be incompatible with standard tools | #9 |
| summary: |
- Cloud-init update renders secondary addresses ti be incompatible with + Cloud-init update renders secondary addresses to be incompatible with standard tools |
| description: | updated |
| Changed in curtin: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| Changed in cloud-init: | |
| importance: | Undecided → Medium |
| Changed in resolvconf (Debian): | |
| status: | Unknown → Won't Fix |
| James Falcon (falcojr) wrote | #10 |
| Changed in cloud-init: | |
| status: | Confirmed → Expired |
The network config in the previous bug used DHCP on v4 and v6; it appears this instance has a different network config injected. Can you attach the network configuration?
As a workaround, you can include a nameserver configuration
- type: nameserver:
address:
- 8.8.8.8
- 8.8.8.3
Or also include the dns-nameservers attribute in the second subnet configuration.
This will render dns-nameservers entry under lo
which will get picked up.
Given the above config, it looks like the ifupdown resolveconf hooks are not multi-iface-stanza aware.