maas not detecting nodes

Mark Shuttleworth mark at
Fri Feb 10 19:39:30 UTC 2017

On 10/02/17 08:17, Mike Pontillo wrote:
> Yes and no; this >5000 value is used as the resource URI, to ensure
> that it remains constant even if the VID is changed. So its exposure,
> although unfortunate, is there. But for usability, we support a
> Fabric/VID style URI... because typically an administrator would
> identify the VLAN by its VID. (The VID being a prevalent and
> meaningful identifier to a system and/or network admin.) By forcing
> the surrogate key to start >5000, we enable the Fabric/VID API usage
> in a simple way.

Well, hold on. If you are suggesting that we use URL's like
/foo/vlan/5020 and expect people to know that the 5020 is not actually a
weird vlan, then I disagree. If you're suggesting something else, I
couldn't follow, sorry for being dense :)

> When MAAS sets up the DHCP configuration, it maps each VLAN in MAAS to
> a shared-subnet in the DHCP configuration. If a trunked link
> terminates on the MAAS rack, MAAS will see each separate VLAN the
> trunk consists of, and for each DHCP-enabled VLAN will generate a
> shared-subnet for each one. Each shared-subnet would need a [tagged]
> VLAN interface to communicate on in this situation.

Hmmmm.... this is basically right, I just wouldn't call it a
shared-subnet (don't know what that is).

> That is, on the surface, there is a 1:1 mapping between a MAAS VLAN
> and one of these mentioned DHCP configuration entries. If you want get
> pedantic, starting in MAAS 2.2, we are supporting DHCP relay. So you
> might also see "remote" VLANs' subnets which are *served via* the
> connected VLAN here. (But it would be difficult to capture that
> meaning in this identifier, since the shared-subnet could be serving
> multiple relayed networks.)

Generally, I find that auto-creating something just to maintain a 1:1
relationship with something else is a bad idea. It leads to making up
names for things. As in this example.

>      * we would make up an identifier of the form hexhexhex or
>     similar, separate from any database primary key id, and use that
>     as a name
> Rather than making up a new identifier, I think it would be nice to
> make it more meaningful to the user.
> You mentioned network segments, and that starts to sound like we're
> talking about fabrics. (Which makes sense, since that's how we qualify
> the namespace of a VLAN.) So I would suggest making the identifier
> something like "fabric-1--vlan-2". (Which would indicate the DHCP
> configuration for VID 2 on fabric-1.) You could also have
> "fabric-1--untagged", etc. That would meet the "don't leak database
> internals" requirement, and make it immediately useful, so that if you
> see this in the syslog:
> Feb  9 11:23:06 dl-360-143 dhcpd[18398]: DHCPDISCOVER from
> 3c:a8:2a:fc:18:50 via eno49: network fabric-5--vlan-2: no free leases
> ... then you immediately know how to browse to the VLAN in MAAS,
> without having to ask on the mailing list. ;-)

Yes that sounds more useful indeed :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Maas-devel mailing list