maas-devel team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 30/05/14 05:55, Julian Edwards wrote:
>
>>> So summarising all of these changes:
>>>
>>> mac_address:
>>>   existing columns:
>>>   * MAC
>>>   * Node (FK)
>>>   * networks (m2m)
>>>   new columns:
>>>   * nic name
>>>   * ip_address (FK)
>>>   * tags
>>>   * metadata (bandwidth etc)
>>>   * bonding info (future)
>> I'm a bit concerned about our modelling of Networks, looking at this. I
>> guess we are trying to reflect that a single MAC might be allowed to
>> join a range of VLANs through its switch? 
> That's right, yes.  It's not just VLANs though, the Linux kernel can
> quite happily connect to multiple networks over the same NIC if you
> don't mind many networks on a single physical connection.

Right, aliases.

In that case, it would be useful to be able to *specify* the aliasing.
DHCP can't use that (though we would know that the base IP is the one
DHCP sends) but something like cloud-init *could* use the info to set up
the network aliases. So the user could essentially say "here are the to
network aliases I want on that interface" and after the boot was done,
voila, they'd be in place.


> Here's the current thinking:
>
> mac_address renamed to node_nic:
>   existing columns:
>   * MAC
>   * Node (FK)
>   * networks (m2m)
>   new columns:
>   * nic name
>   * tags
>   * metadata (bandwidth etc)
>   * bonding info (future)
>
> New table IPAddress, contains in-use IPs only:
>   * IPAddressField
>   * Node_nic (FK, nullable)
>   * metadata (future)
>   * type (auto, sticky, unmanaged, extra, etc)

Perhaps add "alias" an int, uniqued, nullable, so we can model all the
aliases (null being the base NIC IP that DHCP sends).

I don't think Dean's case actually belongs in this table at all. We
don't write Dean's "spare" IP addresses into DHCP, we just BLOCK them
from being used in DHCP, they are reserved for the user. They are more
like entries in DHCPhost that don't actually have mac addresses
associated with them.

>
> New table DHCPHost:
>  * mac (MAC)
>  * ip_address (FK)
>  * name
>  * custom_dhcp_config
>
> Given that we really need all allocated IPAddresses in a single table
> (otherwise we're going to have nasty queries spanning many tables to
> find a free IP), and that IPs may or may not be associated with a node,
> I see no choice but to put a nullable FK to mac_address in it.  The only
> way around this is to create a link table, which may be beneficial if we
> want to model VIPs so they are tied to many MACs, but from Dean's email
> it sounds as though we don't, and what he's really after is an IPAddress
> linked to a user as originally suggested.
>

OK.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature