Merge lp:~rvb/maas/big-networks into lp:maas/trunk
| Status: | Merged |
|---|---|
| Approved by: | Raphaël Badin on 2012-10-08 |
| Approved revision: | 1191 |
| Merged at revision: | 1205 |
| Proposed branch: | lp:~rvb/maas/big-networks |
| Merge into: | lp:maas/trunk |
| Diff against target: |
152 lines (+60/-6) 4 files modified
src/maasserver/models/nodegroupinterface.py (+26/-4) src/maasserver/tests/test_fields.py (+3/-0) src/maasserver/tests/test_forms.py (+2/-2) src/maasserver/tests/test_nodegroupinterface.py (+29/-0) |
| To merge this branch: | bzr merge lp:~rvb/maas/big-networks |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gavin Panella (community) | 2012-10-05 | Approve on 2012-10-05 | |
|
Review via email:
|
|||
Commit Message
Reject networks >= /8 networks.
Description of the Change
Reject networks >= /8 networks. This ends up pre-populating a huge zone file that neither celeryd nor bind handle properly.
| Gavin Panella (allenap) wrote : | # |
Fwiw, I'm not against letting people specify a /8 if they want to. It's just that MAAS will grind to a halt right now, and appear desperately broken, and I think it's better to politely say "non" earlier in the process than to let it break like that.
- 1187. By Raphaël Badin on 2012-10-07
-
Only look for big networks in managed interfaces.
- 1188. By Raphaël Badin on 2012-10-07
-
Fix tests.
- 1189. By Raphaël Badin on 2012-10-07
-
Merge trunk.
- 1190. By Raphaël Badin on 2012-10-07
-
Fix test.
| Raphaël Badin (rvb) wrote : | # |
> This still allows for a network of ~8.3 million addresses. While we're
> generating the full zone maps, it seems ridiculous to support anything
> remotely close to that. If we want to support a flat network for 100k nodes
> then a /15 is all we need, but even that is slightly unhinged right now. A /16
> is far more than enough for the size of cluster we're expecting (*dreaming*)
> of supporting, and if we want more than that we need to get rid of the pre-
> generation stuff, or rethink it (e.g. serve it up dynamically).
You're definitely right… but I think it would be good to allow for a 100k network so I changed the limit to "/15". We can adjust that after doing so testing if we need to.
| Julian Edwards (julian-edwards) wrote : | # |
On Sunday 07 October 2012 17:34:21 you wrote:
> > This still allows for a network of ~8.3 million addresses. While we're
> > generating the full zone maps, it seems ridiculous to support anything
> > remotely close to that. If we want to support a flat network for 100k
> > nodes
> > then a /15 is all we need, but even that is slightly unhinged right now. A
> > /16 is far more than enough for the size of cluster we're expecting
> > (*dreaming*) of supporting, and if we want more than that we need to get
> > rid of the pre- generation stuff, or rethink it (e.g. serve it up
> > dynamically).
>
> You're definitely right… but I think it would be good to allow for a 100k
> network so I changed the limit to "/15". We can adjust that after doing so
> testing if we need to.
Yeah we had agreed /16 in the pre-imp I had with you :) /15 is ok too.
| Julian Edwards (julian-edwards) wrote : | # |
I think MINIMUM_PREFIX_LEN isn't an informative constant name as it could be.
Perhaps MINIMUM_
- 1191. By Raphaël Badin on 2012-10-08
-
Rename MINIMUM_PREFIX_LEN into MINIMUM_
NETMASK_ BITS. Set minimum to /16.
| Raphaël Badin (rvb) wrote : | # |
>
> Yeah we had agreed /16 in the pre-imp I had with you :) /15 is ok too.
Really? I confess I don't really remember :). /16 it is then.
| Raphaël Badin (rvb) wrote : | # |
> I think MINIMUM_PREFIX_LEN isn't an informative constant name as it could be.
> Perhaps MINIMUM_
Ok, done.


Looks good.
[1]
+# For instance, if MINIMUM_PREFIX_LEN is 9, a /8 will be rejected.
+MINIMUM_PREFIX_LEN = 9
This still allows for a network of ~8.3 million addresses. While we're generating the full zone maps, it seems ridiculous to support anything remotely close to that. If we want to support a flat network for 100k nodes then a /15 is all we need, but even that is slightly unhinged right now. A /16 is far more than enough for the size of cluster we're expecting (*dreaming*) of supporting, and if we want more than that we need to get rid of the pre-generation stuff, or rethink it (e.g. serve it up dynamically).