maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Friday 23 May 2014 09:13:34 Mark Shuttleworth wrote:
> On 23/05/14 09:05, Julian Edwards wrote:
> > Based on the discussions here, I suggest these model changes:
> > 
> > Network table gains columns:
> >  subnet, broadcast, router
> > 
> > New table "IPAddress" with columns:
> >  * Node (FK), mac_address (FK), ip_address (IPAddress field type), network
> > 
> > (FK), type (enum)
> > 
> > "type" is "allocated" (by maas) or fixed (by admin), can be extended later
> > if we need.
> 
> How does this let me specify a custom machine (not managed by MAAS) that
> I want in the DHCP? I.e. I have an appliance that I want to show up at
> 192.168.9.9, I want to tell DHCP about its MAC, name and IP. It is not a
> node in MAAS database so an FK to node+mac won't work.

Assuming we have a nullable Node FK it would be OK, but I had not considered 
the NIC bonding that we want to do at some point, so I think your new table 
below makes sense for that.

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

Anyway, the existing mac_address table is basically the same as what you have 
here so we could just fold these new columns into that.  mac_address already 
has a many-to-many relationship with the network table (for LLDP data 
collected on the node when commissioning, or manual admin entries) so we 
should make use of that in any reference to a MAC.

Also, I think we should have a separate table for IP address and FK to it from 
all the places that reference a static IP.  That will make it easier when we 
do allocation from the static pool to allocate unused entries.  We could also 
use it to store extra metadata on an IP, for example further dhcpd host{} 
customisation.

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

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.

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)

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

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)

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

J.

Attachment: signature.asc
Description: This is a digitally signed message part.