On Thu 11 of Apr 2013 9:49:12 Radek Novacek wrote:
On Wed 10 of Apr 2013 13:25:31 Jan Safranek wrote:
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
Yes, this seems like good way to go.
I'm now thinking about usecase, where one might want to have e.g. static IPv4 and DHCPv6 for IPv6... I think this version of the creation method might work:
CreateIPSetting( enum IPv4Type = { Disabled, Static, Dynamic }, enum IPv6Type = { Disabled, Static, Dynamic })
Maybe even those CreateBondSetting and CreateBridgeSetting could be merged to this method by adding another argument that would determine whether we're creating "normal" setting, bridge or bond. Bridging and bonding would still need one more method for enslaving devices.
So in the end, we would have something like that:
class IPNetworkConnectionCapabilities { CreateIPSetting( enum IPv4Type = { Disabled, Static, Dynamic },
It might better to name the third option DHCP, to correspond with created class called DHCPSettingData.
enum IPv6Type = { Disabled, Static, Dynamic },
Here we should cover stateless configuration too. I suggest following:
enum IPv6Type = { Disabled, Static, DHCPv6, Stateless },
enum Type = { Normal, Bonding, Bridging })
Maybe even better would be to name the first type 'Ethernet' (in future there would go other stuff like Wifi etc.)
};
Name of the arguments might be different (suggestions welcomed).
Do you agree with suggested method prototype?
Radek Novacek
Any objections to this suggestion? If not, I'll start to implement it.
Radek