Tracker #2409
Updated by Marek Hulán over 9 years ago
To support networking within foreman. This is more the concept of a nice data structure for networking. This would be eth | bond | vlan | bridge Bearing in mind RHEL 6 versions with SMBIOS 2.6 will have the devbiosname convention so eth may not be applicable in terms of the device. I guess the provisioning templates would need to be setup in a way to interpret the data held in a generic way, but that data be available from the API / internally as other data is now. Perhaps this would be better abstracted like the disk layout is and having a network management area that can deal with this. Currently i have implemented python code, which pulls all the host parameter data (there is a bug request for this to be available via the api) filters on specific named variables; i've chosen: eth|vlan|bond as this is the use case for ourselves, but probably will be greater in other places. The validation i have performed is: 1) A VLAN has to have vlan???_device defined to know what device to associate the vlan with 2) bond?_interfaces also has to be defined to know the interfaces 3) bond?_interfaces also will check whether those interfaces have also been configured by mistake with address details and there is a conflict there. 4) An IP has to have a netmask 5) A netmask or gateway has to have an IP defined If it's a plain eth it can be configured as expected, if eth is in a bond it obviously will have different elements. It is also nice that currently with host paramters, you can override i.e. i could define a bond mechanism i.e. eth0,eth1 for bond0 and that be inherited and if necessary can be overriden, this is useful for standardising on bond configurations, so that feature would also be useful if it is done within foreman. Hope this information helps.