maas-devel team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 26/05/14 09:15, Julian Edwards wrote:
>
>> Instead, I think you need:
>>
>>  * to split out NIC from Node so you can tag and mark up data about each
>> interface on the Node
>>
>>     Table  NIC
>>      * MAC
>>      * ip_address
>>      * tags
>>      * relevant metadata - bandwidth etc
>>      * in future, details of things like bonding
> It would be nice to add a NIC name here too, but one of the reasons we 
> eschewed storing NIC data in favour of a mac_address table is because we saw 
> that on systems with multiple NICs the kernel would assign the NIC name 
> randomly.  However, I just thought that we could inject cloud-init data to 
> write udev rules so that you get control of that.

Indeed, and that's just what we'd have to do for things like bonding
control via MAAS in any event.

We will probably need the same for RAID, on the disk front.

Don't consider the table outlines complete, there is plenty more we'll
want to store about those entities.


>>  * to add a table for custom machines I want to tell MAAS about
>>
>>     Table DHCPHost
>>       * mac
>>       * ip_address
>>       * name
>>       * custom_dhcp_config (stuff that gets dumped into the DHCP config
>> file entry for this host, validated for injection attack safety
>>
>>  * to add a table for the on-demand additional IP address allocations,
>> which would be bound to Node
>>
>>    Table Extra_IP
>>      * node (FK)
>>      * mac (this *might* be an extra IP for the same NIC but might also
>> be a fake mac for the container / VM)
>>      * ip_address
> It would make sense to put custom_dhcp_config somewhere else so that regular 
> static allocations can make use of it (the dhcpd doesn't know about "hosts", 
> it knows about MACs and their IPs).

host apc3 {
        hardware ethernet 00:c0:b7:5c:02:b6;
        fixed-address 192.168.1.32;
}

Looks like a "host" to me. You're right but only pedantically so; I
specifically called it "DHCPHost" because I wanted the ability to "add a
host entry to the DHCP config" via this table.


> However given that we want to record custom machines that maas doesn't have as 
> nodes, it would need to be duplicated in another table.  We could avoid that 
> by FKing the MAC of the custom hosts, putting this new field in the 
> mac_address table, and making its Node column nullable.  But let's leave that 
> for now.

The table of "NICs in Nodes" is much more interesting than the table for
"additional DHCP hosts I need to inject in the DHCP config". Conflating
those two just because you can overloads the more important table and
weakens its relationship to Node.

>
> 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? We'll need to dig in to that
together at some stage. It might be better to call this table node_nic
since that's what it really is.

> New table IPAddress, contains in-use IPs only:
>   * IPAddressField
>   * metadata (future)
>   * type (allocated, static, etc)

Hmm... where is the relationship to the node_nic? I assume we've pulled
it out because of nic aliasing? A single host could get multiple IP
addresses? If so, how do we actually deliver this information to the
node over DHCP? Or is this a sideband for a Juju machine agent to use
directly talking to MAAS?

> New table DHCPHost:
>  * mac (FK, if we decide to make mac_address.node nullable)
>  * ip_address (FK)
>  * name
>  * custom_dhcp_config
>
> New table ExtraIP:
>  * node (FK)
>  * MAC (I think this should be FK so we get the benefits mentioned above, we 
> just need to remove the mac_address entry at the same time as the ExtraIP is 
> de-allocated)
>  * ip_address (FK)

What's ExtraIP doing that IPAddress isn't? This looks wonky to me.

> If we make node a nullable FK the last two tables could be merged.

Please don't, as discussed above.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature