This is a wikified post documenting the system level logic behind the network interface management in Rockstor. If you are a Linux or NetworkManager expert and like to suggest improvements, please feel free to edit this post or reply.
The process described below will take effect in 3.8-8. Code has already been merged into master by pr #884 and available in testing repo.
##User story
User can configure network interfaces on the system from the Web-UI. DHCP and Static IP configurations must be supported for ethernet devices. User can also restrict all Web-UI management to be possible only through one interface.
##System level tools used
NetworkManager is the primary application used by the backend, which is default in CentOS. Specifically, nmcli is used to interact with NetworkManager for all configuration management.
##NetworkManager documentation
I found RHEL7 documentation to be a very good reference. Of all the ways to interact with NetworkManager, nmcli is the obvious winner.
##Assumptions and Conventions
Currently, only ethernet devices are supported. So device type mentioned below is always ethernet. Also, connection name, interface name and device name are the same. We can use different naming, but since it’s one to one mapping, we are keeping things simple.
##Config process
User configures basic networking during OS install, may configure just one interface, which is required by Rockstor. Once setup is finished in the Web-UI, backend fetches current configuration information of the system using nmcli. So configuration made outside of the Web-UI using nmcli is honored by Rockstor.
When user edits configuration of a connection/interface, the existing connection is deleted and a new connection by the same name is added. The command used to delete is nmcli c delete <name>. The command to add is different based on dhcp or static configuration.
I am not sure if deleting and then adding a new connection is reliable as the connection can be deleted but error out on add. In my testing it’s been reliable, no loss of connections or any interruption. And it keeps the code clean and simple.
##Auto/DHCP config
When the user edits a connection to use Auto/DHCP, the command to create the new connection is nmcli c add type <device type> con-name <connection name> ifname <interface name>. That is all! If there is any error at nmcli level, it’s bubbled up to the Web-UI.
##Manual/Static IP config
In case of static IP configuration, we do basic input validation for subnet mask etc., but for the most part just pipe the user input to nmcli.
First, a new connection is created with nmcli c add type <device type> con-name <connection name> ifname <interface name> ip4 <ip_address>/<subnet_bits> gw4 <gateway ip address> command. gateway is optional and only used if the user provided a value.
dns_servers is also optional, but if provided, the following command is executed nmcli c mod <connection name> ipv4.dns <comma separated dns server ip's>
Just like in Auto/DHCP config, if there is any error at nmcli level, it’s bubbled up to the Web-UI.
##Link aggregation.
Coming soon, I played with teaming and it seems to be the recommended option over bonding.
##Misc notes
Since Web-UI itself requires network communication to function, certain edits may cause temporary disruption or may need the user to ssh or connect to terminal in someway to fix. There are appropriate tooltips and warnings on the Web-UI for such scenarios, and they can all be easily avoided. Suggestions for improvement are welcome, as always!