extend linux plugin

[matus-mrekaj]

No description provided.

[milanlenco]

So far looks good, but it will need couple more things to support resync:

• Here in Create you will need to configure alias for the interface to mark it as agent-configured and store its logical name to be able to implement the Retrieve function (i.e. function that reads the state of data-plane and returns the actual config, which is then compared with desired config to determine the set of operations to execute to get those two in-sync). For example, for TAPs (which also already exist in Create from the linux plugin point of view) this is done here. I would suggest alias like: agentPrefix + "/existing/" + logical-interface-name
• Delete should then remove the alias, like it is done here (it will be probably better to move all the EXISTING-related stuff to interface_existing.go so that the main descriptor file contains only the code shared by all interface types)
• here in Retrieve the first if branch should check the alias if there is the "/existing/" substring before checking if it is TAP or VETH, and return it as EXISTING interface (with the name parsed from the alias) if it is the case.

With that the resync should work - to test that you can:

1. start agent and put some configuration into etcd (with EXISTING interface)
2. turn off the agent and change configured EXISTING interface(s) via Linux CLI (e.g. remove/add IP address)
3. (re)start the agent - the first transaction should re-read etcd content and get the network configuration in-sync - i.e. it should revert changes done in 2.

Similarly you can change the desired config in step 2. by changing the etcd content, but keep the network config (actual state) untouched, and then in step 3 the agent should reflect those changes.

EDIT: I realized that it is going it be somewhat more complicated than that - for EXISTING interface created by another agent, the alias is already used by that agent and cannot be changed.
Therefore keep Create/Delete as you already have and alternatively try to implement Retrieve for EXISTING as follows:

• List interfaces in the default namespace (i.e. namespace of the agent)
• filter out those whose alias starts with this agent's prefix (i.e. non-EXISTING interfaces configured by the same agent)
• filter out those interfaces which are not mentioned in the correlate as desired EXISTING interfaces (i.e. we do not want to touch other existing interfaces, e.g. system interfaces)
• dump IP addresses, state, etc. as for TAPs and VETHs.

But this algorithm for Retrieve will need more testing (using the agent restart) to check if it behaves as desired and potentially make changes as needed. The resync is actually the core functionality of the agent, therefore I always ask everyone adding a new descriptor to test it thoroughly.

EDIT 2: another issue with EXISTING being configured by another agent is that those two agents will be colliding - one may set IP address (since it is desired in his NB), but the other could remove it (because it is not desired by his NB). I think we should discuss whether we want to have multiple agents configuring the same thing - what do you think @ondrej-fabry, @rastislavszabo, @VladoLavor? IMHO, EXISTING would make sense for interfaces already created by something other than vpp-agent (e.g. add IP address to already existing eth0 interface). Then we could use the alias to store metadata for Retrieve as we do for VETHs and TAPs. But in the case of DHCP CNF I would just add this dependency for the DHCP plugin and let the vswitch agent to create AND configure IP address(es) for the interface. The CNF would not need to be run in the privileged mode. Would it make sense @matus-mrekaj?

[matus-mrekaj]

I think the idea of type EXISTING should be just to configure interfaces that already existed before vpp-agent start(interfaces created by something other than the agent) or in the case that the interface is not present yet, configure it later when it is created.
In the case of resync it should be handled by the watcher descriptor, which should take care of this dependency, since we expect the interface to be in the same namespace as the agent. If the interface is not present when the agent starts, then it will wait for the SB notification

Let's say we have a stub network, and the dhcp should listen on that interface, the interface must have a ip address assigned,I think In this case the agent should be able to configure the interface.

[milanlenco]

The problem we are facing is that with the stub network the vswitch agent will create the interface, but it will not assign any IP address to it. If the agent from DHCP CNF does assign and IP address, but then later the vswitch agent restarts, it would run the resync and remove the IP address (since by the vswitch's NB configuration there should be no IP address) - i.e. I can't figure out how to solve the multiple-agents configuring the same interface scenario.
So my idea was to use a non-stub network with IP addresses (other network types to be implemented into Contiv) and let the vswitch to configure the IP address. The question is though, does dhcp depends only on interface being created, or does IP address already has to be assigned when dhcp server is started? Because this dependency does not cover interface having an IP address, so we would need to also watch for IP address add/del events into the watcher.

[matus-mrekaj]

The dhcp depends on the interface to be up and have an ip address assigned otherwise it will not listen on that interface
So if we set a config, for example with ETCD, we get this error:
failed to open socket: the interface tap1 has no usable IPv4 addresses configured
So to bypass this error a make a dependency that waits until that interface is up and has a ip address assigned something like this

EDIT: The dependency on the iface state and ip address should be handled by this when the interface is configured.


EDIT2: Question if the vswitch restarts does it recreate the interface, or just configures it as in NB.
if not i can see that might be a problem if the dhcp is listening on that interface and the ip is removed.

[milanlenco]

Regarding vswitch restart - the dependency on the interface would be also lost and regained which would cause the delete+create sequence also for your dhcp object, i.e. the dhcp server would get restarted.

Regarding the resync: I had a talk about the issues and possible solutions with @rastislavszabo. We decided that for now we would go with the solution based on the EXISTING interface type - i.e. the interface would be created by vswitch, but IP address(es) and other parameters would be set by the agent inside CNF. Maybe in the future we would add option to tell the CNF that the IP address will be set by the vswitch and the CNF should just wait for it to appear. For now I would also suggest to disregard the resync-related issues since we do not need to support the restart scenarios for the planned demo. I will therefore merge this PR so that you are no longer blocked by this and can finalize the CNF implementation. In the meantime I hope to find some spare time that I would use to test some ideas that I have on how to approach the resync in multi-agent scenarios.