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