Network provider modeling

Radek Novacek rnovacek at redhat.com
Tue Apr 9 14:02:19 UTC 2013


During recent patch review [1] we've found out major issues in networking 
provider model (thanks goes to Jan Safranek). I've misunderstood the concept 
of network connection settings and tried to map them to NetworkManager's 
Connections as tight as possible. It seems that authors of the DMTF standard 
had a different vision.

How the model should look according to DMTF (DSP1116 [2]):

All of the following SettingDatas should exist for each network interface:
 1) Static IPv4 (arbitrary number of static IPv4 addresses)
 2) DHCP IPv4 only
 3) DHCP IPv4 then static IPv4 (use DHCP and if available, if not use static 
addresses)
 4) DHCPv6
 5) Static IPv6
 6) Stateless IPv6

More of these SettingDatas could be active simultaneously.


How NetworkManager model looks:

Each network interface can have multiple Connections, each have separate IPv4 
and IPv6 configuration. Connections don't have to be assigned to one 
particular interface.


How to mix it together:

 1) Exactly according to DSP1116:

    Use one "special" NN Connection for each port that represents connection 
created by OpenLMI network provider.

    + DMTF DSP1666 compliance
    - IMHO not intuitive (I couldn't comprehend it from the profile on my own)
    - doesn't handle NM Connections -- this means that current NM 
      configuration can't be displayed
    - must somehow solve conflicts between changes by CIM and changes by
      NetworkManager (and tools using it).

 2) Follow NetworkManager model (that how it's done now)

    Above mentioned SettingDatas don't exists, but there is SettingData for 
    each Connection in NM. Creating and modifying is done by custom methods.

    + More aligned to NM model
    + IMHO easier to understand and use then 1)
    - doesn't follow (some parts of) DSP1116, but has the same classes

 3) Combine both approaches

    Have the 6 SettingData mentioned above still present but add additional
    SettingData per existing NM Connections and have the custom methods
    available.

    + DMTF DSP1666 compliance
    + more possibilities than solution 1)
    + can be added later on
    - a lot of work, potentially complicated


I suggest continuing with 2) because it's already almost ready, (from my POV) 
it's easier to use and it's more powerful then 1). Solution 3) might be doable 
but now it would slow down the progress and it might turn out that this 
approach is no-go.


Any suggestions how to approach this issue are very welcomed.

Thanks,
Radek Novacek


[1] https://reviewboard-openlmi.rhcloud.com/r/148/
[2] http://dmtf.org/sites/default/files/standards/documents/DSP1116_1.0.0.pdf



More information about the openlmi-devel mailing list