maas-devel team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxx>]

Hi Julian,

Overall, I think this is good. I'm just adding some clarifying notes to
your sample config file to make sure that we are talking about the same
things.

Cheers

On 12-05-31 12:20 AM, Julian Edwards wrote:
> Given the trouble with the OMAPI stuff, I'm trying to get to having a static 
> config file instead so that it can be set up once and forgotten about.
> 
> Here's what I think will work based on chats I've had with a few people 
> (thanks Robie!).  Please can people take a look and correct any mistakes.
> 
> Here's the sequence of events:
> 
>  1.  When a new provisioning worker is installed, it contacts the MAAS server 
> (Avahi, or through a known address).  MAAS auto-configures that worker’s node 
> group by auto-allocating an IP range (10.0.0.0/16)

On the network architecture call, we discussed using the 10/8 network
for the MAAS+nodes network. We'll divide the remaining 24 bits in 12
bits for the network and 12 bits for hosts. That gives us a possibility
of 4096 subnets each of 4096 hosts. (In practice, 4093 nodes per subnet
and 4095 racks.) More than enough to die of broadcast traffic anyway.

The MAAS + provisioning worker would be on the 10.0.0.0/20 network - say
with the MAAS on 10.0.0.1.

Then first rack would get 10.0.16.0/20. Let's say the provisioning
worker host is doing the routing, it would have on NIC on the
10.0.0.0/20 network (say 10.0.0.10) and one NIC for the nodes network
(say 10.0.16.1).

The next rack would get the 10.0.32.0/20 network.


>  2.  Alternatively, an admin can manually set up the node group on the MAAS 
> server.
>  3.  MAAS sets up a celery job targeted at that provisioning worker which 
> writes out the required DHCPD config and restarts the DHCPD server.
> 
> The static DHCPD config will have to differentiate between architectures of 
> the requesting nodes, so that the right PXE boot file can be supplied (or 
> faked, in the case of Uboot running on ARM).
> 
> Something similar to this config should work:
> 
> class "pxe" {
>    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
> }
> class "uboot-highbank" {
>    match if substring (option vendor-class-identifier, 0, 21) = "U-
> boot.armv7.highbank";
> }
> subnet 10.1.0.0 netmask 255.255.0.0 {

So that's the provisioning worker subnet. So assuming the above network
architecture where the first rack would get 10.0.16.0/20 that would be:

subnet 10.0.16.0 netmask 255.255.240.0

>        server-name "10.100.0.1";

That's the DHCP server, right? So that would be 10.0.16.1

>        next-server 10.100.0.1;

So that would be also the provisioning worker host, so 10.0.16.1

>        option tftp-server-name "10.100.0.1";

This is also running on the provisioning worker host, so 10.0.16.1

>        option subnet-mask 255.255.0.0;

/20 netmask is 255.255.240.0 (btw, i don't do those in my head, I use
http://www.subnet-calculator.com/cidr.php ;-)


>        option broadcast-address 10.1.255.255;

10.0.16.255

>        option domain-name-servers 1.2.3.4;

We are assuming on dns server for the whole MAAS, right. So that would
always be the MAAS host, so 10.0.0.1?

>        option routers 10.1.0.254;

Assuming the provisioning worker host does the routing, that would be
10.0.16.1. Otherwise, it should be the address of the top-of-rack switch
that does the routing.

>        range 10.1.0.1 10.1.255.255;

range 10.0.16.1 10.0.16.255

(Since 10.0.16.1 is the provisiong worker host and 10.0.16.255 is the
broadcast address, maybe that should be 10.0.16.2 10.0.16.254?)

>        pool {
>                allow members of "uboot-highbank";
>                filename "/arm/highbank/empty";
>        }
>        pool {
>                allow members of "pxe";
>                filename "/x86/pxelinux.0";
>        }
> }
> 
> In this example, separate ‘classes’ are defined for machines with a different 
> vendor-class-identifier, which causes a match in different pool declarations. 
> The different pool declarations then set a PXE filename appropriate to that 
> hardware.
> 
> In the case of the uboot hardware, it doesn’t actually download the file 
> because uboot emulates PXE by having its own file embedded.  However, this 
> does have the effect of setting the directory in which to find the PXE config 
> file.
> 
> I'd appreciate any feedback you may have on this.
> 
> Cheers.
> 


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature