maas-devel team mailing list archive

[Mike Pontillo <mike.pontillo@xxxxxxxxxxxxx>]

   +1. In summary, I would support:

(1) The suggested Node--<Interface model
(2) Integration of the MACAddress object into the Interface object
(3) A new "UNKNOWN" interface type to cover edge cases where we don't know
what type of interface is actually being seen

   I think the trickiest part of (1) and (2) may be maintaining API
compatibility with the current MACAddress-centric model. Our approach so
far has been that MACAddres.<method>() is the same as getting a
Physicalnterface and calling the same <method>, so that could simplify the
transition a little.

Regards,
Mike

On Mon, Aug 24, 2015 at 9:56 AM, Gavin Panella <gavin.panella@xxxxxxxxxxxxx>
wrote:

> [Here's a summary of what we discussed on the team call just now. Please
> reply with corrections or new thoughts.]
>
> Regarding nodes, MAC addresses, and interfaces, the model we have at
> present is:
>
>   Node--<MACAddress--<Interface
>
> This doesn't make a great deal of sense, and is fairly awkward to reason
> about and especially to code for.
>
> The model:
>
>   Node--<Interface>--<MACAddress
>
> seems to better model reality.
>
> Simpler yet, we can merge MACAddress and Interface by storing the MAC
> address as a field on Interface.
>
> When the DHCP lease parser presents a previously unseen MAC address --
> i.e. a DHCP request has originated from that MAC -- MAAS should create a
> Device for it, and label its sole Interface as of UNKNOWN type. This
> surfaces the new network member to the user in a safe way (a Device is
> the most inert of node types) who can later rejig things as necessary.
>
> The MAC address field on Interface should be non-unique.
>