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