MAAS does not factor in BMC addresses to address availability

Bug #1467119 reported by Mark Shuttleworth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Unassigned

Bug Description

On my MAAS network, 192.168.9.3 is an AMT BMC for one of the machines. Its address is therefor not available for any ranges or addresses requested dynamically by the system, yet when I was building a cloud today with landscape, I was offered a range which included this address.

EXPECTED: MAAS will treat BMC / "power control" addresses as being used up and not offer them for static or dynamic assignment, or as part of available ranges.

In short, MAAS should aggregate everything it knows about all addresses when deciding what addresses are used and which are available.

Tags: bmc ha
Revision history for this message
Mike Pontillo (mpontillo) wrote :

This one may be a little trickier to solve than the other case you mentioned (bug 1467120), since in the other case the switch was modeled in MAAS (presumably as a device), whereas in this case the only reason MAAS knows about the BMC is because its IP address happens to be in a power parameter field. We need to model BMCs as "first class citizens" first in order to do this (which is on the roadmap).

Question: In the MAAS "Edit Cluster Interface" screen, what static and dynamic ranges are defined, for the cluster interface that overlaps with this BMC? (It is correct to assume that the defined range overlaps the BMC? Or does Landscape define that? See my qestion to the Landscape team - again, on bug #1467120.)

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1467119] Re: MAAS does not factor in BMC addresses to address availability

On 20/06/15 23:48, Mike Pontillo wrote:
> This one may be a little trickier to solve than the other case you
> mentioned (bug 1467120), since in the other case the switch was modeled
> in MAAS (presumably as a device), whereas in this case the only reason
> MAAS knows about the BMC is because its IP address happens to be in a
> power parameter field. We need to model BMCs as "first class citizens"
> first in order to do this (which is on the roadmap).

Yes, I filed two separate bugs because the internal implementations will
no doubt happen separately.

I believe the intent is model a BMC as another machine, which then lets
us track (all of) its interface MAC addresses and VLANs and IP addresses
in exactly the same way we track the machines we manage directly,
through them. In the case of AMT, the BMC pointer would be
self-referential. But the net effect of all of that is that the
controller mac-and-ip addresses will be in the same tables as normal
machines, if we do it right.

> Question: In the MAAS "Edit Cluster Interface" screen, what static and
> dynamic ranges are defined, for the cluster interface that overlaps with
> this BMC? (It is correct to assume that the defined range overlaps the
> BMC? Or does Landscape define that? See my qestion to the Landscape team
> - again, on bug #1467120.)

The range that Landscape offered (which I assume came from MAAS)
correctly does not overlap with the DHCP and static pool of addresses.

I believe Landscape is calling an API set on MAAS which should look like:

 * how many IPs are in the maximum contiguous range you can give me on
network X?
 * how many non-contiguous IPs are available on network X?
 * please give me Z in a single range, or in a et of ranges.

In responding to those APIs MAAS should consider BMC and device
addresses (and router information :)

Mark

Changed in maas:
importance: Undecided → Medium
Changed in maas:
milestone: none → next
importance: Medium → High
status: New → Triaged
Revision history for this message
Blake Rouse (blake-rouse) wrote :

This is something we will be fixing in MAAS 2.0 for the new HA support. BMC will be modeled correctly and will not just be a free form field on the node.

tags: added: ha
tags: added: bmc
Changed in maas:
milestone: next → 2.2.x
status: Triaged → Fix Released
milestone: 2.2.x → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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