Page History

The NetworkManagerImpl class is the lynchpin of the core networking piece inside CloudStack. It is currently at approximately 8000 LOC. This makes it hard to understand, test and maintain. This is a proposal to break up this important piece of code so that it becomes more maintainable.

The current structure looks like this:

The plugins are separate modules that extend NetworkElement and one or more of the Provider interfaces. ALL plugins extend the NetworkElement even though they do not need notifications of L2 network events. As a result they may leave a lot of methods inherited from NetworkElement as no-ops.
This is an example of 2 network element plugins:

Since the list of NetworkElements are injected into the NetworkManagerImpl class, any operation desired from the plugins by other managers such as the RulesManagerImpl (push static nat rules), FirewallManagerImpl (push firewall rules) is delegated to the NetworkManagerImpl class.

This is unnecessary and leads to code such as

@Override
    /* The rules here is only the same kind of rule, e.g. all load balancing rules or all port forwarding rules */
    public boolean applyRules(List<? extends FirewallRule> rules, boolean continueOnError) throws ResourceUnavailableException 
case Firewall:
                    boolean isFirewallProvider = isProviderSupportServiceInNetwork(network.getId(), Service.Firewall, provider);
                    if (!(ne instanceof FirewallServiceProvider && isFirewallProvider)) {
                        continue;
                    }
                    handled = ((FirewallServiceProvider) ne).applyFWRules(network, rules);
                    break;

The providers can be instead be injected into the respective managers. For example the list of FirewallServiceProvider elements can be injected into the FirewallManagerImpl class.

This will allow us to move code from the NetworkManagerImpl class to RulesManagerImpl, FirewallManagerImpl etc.

Next the NetworkManagerImpl class can be split up into the service and manager components like this:

Finally the NetworkService and NetworkManager classes can be split by functions related to the layer of the networking stack : PhysicalNetworkService , L2NetworkService, PublicIpService. The NetworkManager interface can be similarly split, also the functions that are used by other modules (plugins, managers) to read the network model state can be moved to another class, the NetworkModelInfo interface.