maas not detecting nodes

[Mike Pontillo]

On Thu, Feb 9, 2017 at 11:23 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
>
> It's actually a meaningful name; the '5005' in that example correlates
> directly with the VLAN ID, which should make it relatively easy to find its
> context via the MAAS API if necessary (or the UI, if you feel like browsing
> to a subnet and then manually changing the number at the end of the URL
> bar).
>
> Note that MAAS deliberately starts numbering its VLAN identifiers > 5000
> so that we avoid confusing the surrogate key with a VID like you would see
> on the wire.
>
> This is not nearly as helpful as you think it is.
>
Well, I'm not arguing that it's necessarily helpful to the average user.
(Not intuitively, at least, although perhaps it could be in a support
situation.) I just wanted to clear up the misconception that it's arbitrary.

> We're using the same general terminology for two completely different
> things, based only on the very specialist knowledge that VLANs don't go
> higher than 4096. Also, if I read you correctly, we are leaking the
> internals of a database schema ("vlan database rows have a primary key that
> is an integer over 5000") for no design reason at all. If that's correct...
> nyet, spasibo :)
>
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.

On the other hand, I agree that the exposure of this surrogate key inside
the DHCP configuration file falls short. I would rather it be more
meaningful to the user.

> What I would expect is:
>
>  * we would use the term segment rather than VLAN because the fabric might
> be trunked switches
>
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.

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.)

>  * 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. ;-)

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20170210/b6dd7793/attachment.html>