Network provider modeling

Jan Safranek jsafrane at redhat.com
Wed Apr 10 10:39:43 UTC 2013


On 04/09/2013 04:02 PM, Radek Novacek wrote:
> 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.

I have no strong opinion, just if we continue with 2) or 3), I would
suggest to follow storage model of working with various setting.

Currently the networking provider has method CreateOrModifySetting,
which is the only way to create or modify a LMI_*Setting for networking.

In storage, I usually have method CreateSetting(), which creates default
LMI_*Setting instance and the application then changes it using
ModifyInstance (and DeleteInstance) intrinsic methods.

If we diverge from the standard, we should IMHO use one way how Setting
classes work.

Jan


More information about the openlmi-devel mailing list