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. -- Mailing list: https://launchpad.net/~maas-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~maas-devel More help : https://help.launchpad.net/ListHelp
