[2.5] "Pod does not have a network defined" path causes unexpected behavior

Bug #1788756 reported by Mike Pontillo on 2018-08-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
High
Newell Jensen

Bug Description

I tore down and rebuilt the container I was testing KVM pods in today, and hit some unexpected issues (some in MAAS, some in other packages). That is, due to a related regression (bug #1784501), my pod did not have any networks defined. Therefore, when I went to compose a machine, I hit the following error:

    Pod does not have a network defined. Please add a 'default' or 'maas' network.

I didn't really care that the networks weren't defined, since I was planning to deploy my pods with an interface constraint. So I tried again with an interface constraint, and hit the same error.

There are a couple things wrong in this scenario:

(1) Not having a 'maas' or 'default' network defined should not be a fatal error, as long as MAAS can attach an interface to a DHCP-enabled VLAN (and/or an `interfaces` constraint was specified).

(2) Machines were created in the hypervisor (with zero interfaces) when the API was called.

I'm filing this as one bug, because I think the fix to (1) can also fix (2).

Related branches

Andres Rodriguez (andreserl) wrote :

The “default” and “Maas” networks were required previous from 2.5 for networking to work. That means we should continue to use that if exists for backwards compat.

Also we need to think about the errors that Maas shows when not networks are defined, or it cannot use Bruges or macvtap.

Changed in maas:
milestone: none → 2.5.0beta1
Mike Pontillo (mpontillo) wrote :

Yes, we already uses these networks for backwards compatibility. We didn't plan to change this, although arguably we might now be able to make a better decision - so we should think about it.

However, if neither a "default" or "maas" network exists, we should fall back to attaching to a bridge known to be attached to a DHCP-enabled network.

In the absence of anything else, MAAS should always be able to make some type of macvlan or bridge attachment; the only question is whether or not it will actually /work/. ;-) In the case of macvlan, if the controller resides on the same host as libvirt, the booting node won't be able to contact it unless the macvlan is configured for hairpin (vepa) mode on the attached switch. (That is, unless we have a secondary rack active on the VLAN - but that's another story.)

The other problematic thing with macvlan is that it may not work inside of a container, since it creates a tun/tap device for communication, which may or may not be allowed depending on the container's settings (and even if it's allowed, I've seen cases where it can't find the device file).

Mike Pontillo (mpontillo) wrote :

I just noticed that MAAS will also happily compose a machine with no storage device if you forget to define the default storage pool. Not sure if this is a regression or a new issue that occurs due to the changes to the pod driver in MAAS 2.5.0.

Changed in maas:
status: Triaged → In Progress
Changed in maas:
status: In Progress → Fix Committed
Changed in maas:
assignee: nobody → Newell Jensen (newell-jensen)
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers