Refactor monolithic defaults into modules

[kostko]

This should make it much easier to write defaults modules for new projects. The wlan slovenija defaults now look as follows:

# Defaults for wlan slovenija network.
registration.point('node.config').add_form_defaults([
    DefaultPlatform(platform='lede'),
    DefaultType(type='wireless'),
    DefaultProject(),
    DefaultRandomPassword(),
    DefaultProjectRouterID(),
    NetworkConfiguration(routing_protocols=['babel']),
    STAChannelAutoselect(),
    TunneldiggerServersOnUplink(routing_protocols=['babel']),
    DnsServers(),
])

Everything except NetworkConfiguration has been moved into respective modules. We should probably make that reusable as well, but this is the first step.

This PR also makes a change to the default platform (OpenWRT to LEDE) and the set of default routing protocols used ("OLSR and Babel" to just "Babel").

[mitar]

A nice idea.

I dislike a bit all that apps.is_installed stuff. Maybe these defaults should go to extra namespace? In a way it feels like core provides the concept of defaults, modules provide various things to apply defaults to, and extra then has some reusable defaults across those things.

[mitar]

Also, I am missing documentation for all this. The whole concept of defaults. And what each of those classes do exactly. Maybe we could use docstrings for documenting here and extract automatically? But we also need documentation at high level.

So this is one of aspects I do not know how to use in nodewatcher and we do not have much (none) documentation either. So how to apply those defaults, and how to construct your own.

And tests.

[kostko]

I dislike a bit all that apps.is_installed stuff. Maybe these defaults should go to extra namespace? In a way it feels like core provides the concept of defaults, modules provide various things to apply defaults to, and extra then has some reusable defaults across those things.

But if you check the models themselves you will notice the same thing -- for example, if you have project support, then DNS and tunneldigger servers can be configured per-project. This is not in a separate module. So to me, it seemed logical that defaults also follow this pattern. Otherwise I am afraid that there will be too much fragmentation (e.g. even more modules).

[mitar]

Oh, I see. defaults.py are in fact part of each module. OK, this makes sense.

[kostko]

Also, I am missing documentation for all this. The whole concept of defaults. And what each of those classes do exactly. Maybe we could use docstrings for documenting here and extract automatically? But we also need documentation at high level.

So this is one of aspects I do not know how to use in nodewatcher and we do not have much (none) documentation either. So how to apply those defaults, and how to construct your own.

And tests.

I agree, but currently I don't have time to do that, so I am pushing out things in small pieces. This refactor doesn't add any new functionality it just makes the code more readable. I know that documentation would be very welcome and I plan to add it sometime in the future.

For the concept we had that written somewhere when designing this whole nodewatcher v3. Defaults are an alternative to configuration templates. Consider them something like dynamic templates, which can configure themselves based on what the user has already configured (e.g. they fill in some gaps automatically to ease configuration).

[mitar]

OK, then let's go without documentation. :-(

[kostko]

I will work on documentation for this after I finish the Django 1.10 migrations. It is almost done, I haven't yet made a PR but it is a big one as we need to port everything away from Tastypie.

[mitar]

OK.