maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 19 July 2012 09:48:16 Raphaël Badin wrote:
> Le 19/07/2012 08:41, Robert Collins a écrit :
> >[...]
> >
> > To expand on this, there are two cases where we have to deal with a
> > 
> > partial octet:
> >   * External user splits: the user already has the same network range
> > 
> > they are giving to MAAS in use and MAAS is being given a slice of
> > that.
> > 
> >   * Within-MAAS splits: the user is carving out some of the ip range
> > 
> > MAAS has to be a node group with its own dedicated image server/TFTP
> > etc.
> 
> A less drastic approach than forcing a user to give MAAS classful
> networks would be to "avoid the collisions".  I mean calculate, each
> time a new network is added to MAAS (i.e. when a new nodegroup is added)
> if this new network will conflict with any of the existing networks and
> if it's the case, have MAAS refuse it.
> 
> >> We do have to bear in mind that people simply playing with MAAS (the seed
> >> cloud story) may not have control of a DHCP server on their network.
> > 
> > Totally! There is AIUI an option that says 'run DHCP or use existing',
> > and if use existing is set we just don't do anything about DHCP
> > settings. If we manage it, we can assign to the right pool on
> > enrollment.
> 
> On could argue that people simply playing with MAAS will only have one
> nodegroup (the default nodegroup created when MAAS is installed) and
> thus MAAS will have only one network to manage.  If we use the solution
> I describe above, then there is no risk of collision in that case.  For
> real deployments, advising the user to allocate classful (private)
> networks seems reasonable to me.
> 
> R.

I'm tempted to agree for now, just to move past this problem.  Let's implement 
the collision detection anyway (when we do the hyperscale work) because it 
seems like a sensible check to make regardless.

Cheers.