MAAS

[1.9] eth0 tried to get a DHCP IP, no matter what

Bug #1612293 reported by Zoltan Arnold Nagy
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Invalid
Undecided
Unassigned
curtin (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

With the latest relase trusty images using 1.9.4 and cloud-init 0.7.5, this file is causing problems:

root@c12n8:/etc/network/interfaces.d# cat eth0.cfg
# The primary network interface
auto eth0
iface eth0 inet dhcp
root@c12n8:/etc/network/interfaces.d#

even if eth0 is unconfigured in MAAS, it will try to get a DHCP on eth0.

if it succeeds (as for example my bond0 [from different network interfaces than eth0] has the same /24 network that my eth0) that could cause random network issues.
if they are not on the same network, it changes the default gateway which makes the node inaccessible (depending on the network's configuration) on it's bond0 IP (which is the intended address for the machine)

Revision history for this message
Zoltan Arnold Nagy (zoltan) wrote :

sadly I can't bump up the severity of this but this can cause serious network connectivity issues. :(

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Zoltan,

The bug is not in MAAS. The bug is in cloud-init.

Thanks.

Changed in maas:
status: New → Invalid
Revision history for this message
Zoltan Arnold Nagy (zoltan) wrote :

While I understand where you're coming from I think MAAS users shouldn't really care *where* the bug is. It manifests itself in something that's not in line with the MAAS config. If in MAAS I don't have eth0 configured then it should NOT be configured, no matter what.

The MAAS source images are produced by you guys, right? If so, you could make sure that the images include a recent enough cloud-init as the sister bug to this in cloud-init has been marked fixed for 0.7.7, while the image only has 0.7.5 in there IIRC.

Revision history for this message
Zoltan Arnold Nagy (zoltan) wrote :

this is the sister bug I was mentioning; says it should NOT delete it, but it should...

https://bugs.launchpad.net/cloud-init/+bug/1563487

Revision history for this message
Andres Rodriguez (andreserl) wrote :

MAAS images are no different than Ubuntu cloud images. In essence, they are the same exact thing. That said, MAAS can uses one of two streams, the "released" streams or the "daily" streams. The "daily" streams is where new MAAS images get updated with latest package updates.

If you are using releases, then you don't have the latest images with the latest packages.

If you are using daily, then you should have the latest images with latest packages.

That said, MAAS also auto-imports new images, if it is configured to do so. By default, it should be importing new available images, but if you are using the 'releases' stream, then you wont have new images.

That said, you need to:

1. Ensure you are using the daily streams to get images with the latest updated packages.
2. Ensure Automatic image import is enabled.

Revision history for this message
Scott Moser (smoser) wrote :

Hi,
I've moved this from cloud-init to curtin, and marked 'fix-released'.
I believe that it was fixed in curtin at
 http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/421?start_revid=421

Basically, installs using curtin will now delete that file from the installed image.

If this is still a problem for you with a curtin in xenial or newer, please re-open.
If you're using curtin on trusty, then you'll need an SRU of curtin version > 421.

affects: cloud-init (Ubuntu) → curtin (Ubuntu)
Changed in curtin (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.