Network provider modeling

Radek Novacek rnovacek at redhat.com
Mon Apr 15 08:40:49 UTC 2013


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



More information about the openlmi-devel mailing list