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