<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 9, 2017 at 11:23 PM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><blockquote type="cite"><div class="gmail_extra" dir="auto">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).</div>
<div class="gmail_extra" dir="auto"><br>
</div>
<div class="gmail_extra" dir="auto">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.</div></blockquote>
</span><p>This is not nearly as helpful as you think it is.</p></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<p>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 :)</p></div></blockquote><div>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.</div><div><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<p>What I would expect is:</p>
<p> * we would use the term segment rather than VLAN because the
fabric might be trunked switches</p></div></blockquote><div>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.</div><div><br></div><div>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.)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p> * 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</p></div></blockquote><div>Rather than making up a new identifier, I think it would be nice to make it more meaningful to the user.</div><div><br></div><div>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:</div><br>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<br><br>... then you immediately know how to browse to the VLAN in MAAS, without having to ask on the mailing list. ;-)<br><br><div>Regards,</div><div>Mike</div></div></div></div>