Network provider modeling

Jan Safranek jsafrane at redhat.com
Wed Apr 10 11:25:31 UTC 2013


On 04/10/2013 01:11 PM, Radek Novacek wrote:
> On Wed 10 of Apr 2013 12:39:43 Jan Safranek wrote:
>> On 04/09/2013 04:02 PM, Radek Novacek wrote:
>>> <snip>
>>
>> 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
> 
> I could split the the creation of setting to the two parts - creation an empty 
> setting and then modifying it, but the CreateSetting method would need 
> additional arguments to set following:
>  * ProtocolIFType -- do we want to create Setting IPv4, IPv6 or both
>  * What type of setting should be created (which subclass of
>    IPAssignmentSettingData should be created -
>    ExtendedStaticIPAssignmentSettingData or DHCPSettingData)
>  * IPNetworkConnection - port to which should be the Setting associated
>  * Type - are we creating setting for bridge or bond or normal one?
> 
> Some of these options can't be easily set up later, because it affects which 
> classes will be created, others would require additional action (like creating 
> association to IPNetworkConnection by hand).
> 
> 
> Can you see any way how to do solve this in some nice way? Or are there some 
> classes in storage that solve something like that?

In storage, I have many LMI_*Capabilities classes. Each of them
describes which settings can be created and e.g. supported properties
and their values. Each of them has CreateSetting method, which creates
instance of LMI_*Setting - e.g. LMI_StorageCapabilities.CreateSetting()
creates LMI_StorageSetting, LMI_FileSystemCapabilities.CreateSetting()
creates LMI_FileSystemSetting etc.

In addition, there can be multiple instances of the Capabilities class -
e.g. LMI_FileSystemCapabilities has one instance for every filesystem
type we support. It then describes valid properties and valid values
specific for one filesystem. E.g. that vfat is case insensitive while
ext3 is case sensitive regarding file names.

In addition, sometimes are LMI_*Capabilities associated to
ManagedElements, e.g. each volume group has associated
LMI_LVStorageCapabilities, which describes, which logical volumes can be
allocated from it. In theory, each volume group could be specialized, of
course our LVM does not support that.

Not being expert on networking model, I would propose to create
LMI_IPNetworkConnectionCapabilities class. Each IPNetworkConnection
would have one instance of IPNetworkConnectionCapabilities associated.
The IPNetworkConnectionCapabilities would have methods:
* CreateIPSetting(ProtocolIFType, type_of_setting_to_create (some enum>
or separate methods?))

* CreateBondSetting(...)

* CreateBridgeSetting(...)

-> the created setting would be automatically associated to
IPNetworkConnection associated with IPNetworkConnectionCapabilities.

Does it sound meaningful?

Jan


More information about the openlmi-devel mailing list