maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Wednesday 28 May 2014 12:49:29 Mark Shuttleworth wrote:
> > 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.

I am using host in the traditional sense rather than the dhcp sense. I
guess the config format was written in the days before it was common for
machines to have multiple NICs.

It is possible to have multiple dhcp host entries per actual host, so it
makes sense to me to differentiate with the terminology.   This level of
confusion has been the source of some bugs.

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

Agreed.

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

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

Agreed.

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

Mac_address/node_nic has a FK to this table, so we could cover the use
case of virtual IPs that Dean wanted, which map to many MACs.  However
since sending that email I made another revision to the schema as we
also need to cover the case you describe where a single NIC has many IPs.

In that scenario we would need to write a host{} block for every IP each
in its own subnet.  The rest of the code can't do that yet, but we can
make sure the model is right now.

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

This is another change to the design since I sent that email - ExtraIP
is now obsolete and I'm just using IPAddress.

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)

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.

J