dranet has no EventRecorder plumbed today

[aojea]

Reported in #193 by @wevans-ant , opening a new issue so we can track it and implement it

[fmuyassarov]

Happy to help with the task
/assign

[gauravkghildiyal]

Thanks for volunteering @fmuyassarov

It'd be nice if we can identify first where and how we'll use events (e.g. which resource types will we tie events to)

[fmuyassarov]

Yep, I think I’ll have a lot of questions on that front as well. My plan is to come up with the initial idea here first, and then we can discuss about that plan and agree before I file the final implementation PR.

[fmuyassarov]

Hi @gauravkghildiyal @aojea .

Here is my rough idea and I'm sure I've missed some errors worth of its own event or thinking of an event which doesn't really worth of its event. But as agreed, let's discuss and agree here and then I will move on with the implementation.

List of the events I'm thinking to start with is as below and below I'll try to explain what does each represent or what is expected from the UX perspective when user gets such an event.

• DevicePrepareFailed
• NetworkDeviceAttachFailed
• NetworkDeviceAttached
• NetworkDeviceDetachFailed
• RDMADeviceAttached
• RDMADeviceAttachFailed
• ClaimPrepareFailed

DevicePrepareFailed - we hook this into prepareResourceClaim(). prepareResourceClaim()currently collects per-device failures into errorList through the device and we emit an event per failure which could be either of these

• GetNetInterfaceName() - device not found in inventory
• LinkByName() - interface disappeared from the host
• getRouteInfo()- failed
• SetDeviceConfig() - checkpoint write failed

There is also nlwrap.NewHandle() and getRuleInfo() errors which aren't part of errorList and if we end up there, perhaps we could use something like ClaimPrepareFailed for the event name and not DevicePrepareFailed because they happen prior to the device loop related events.

---

NetworkDeviceAttachFailed - hooks into attachNetdevToNS(). We could produce this event whenever any of the following errors happen during attachNetdevToNS().
nsAttachNetdev() - failed to move interface into pod netns
applyEthtoolConfig() - ethtool config failed inside pod netns
detachEBPFPrograms() - failed to detach eBPF programs
applyVRFConfig() - VRF setup failed
applyRoutingConfig() - route configuration failed
applyRulesConfig() - ip rule configuration failed
applyNeighborConfig() - neighbor (ARP) entry failed

---

RDMADeviceAttachFailed - also hooks in to attachRdmaToNS() but we create a separate event for the failure of
moving the RDMA link device into pod netns.

---

NetworkDeviceDetachFailed - hooks into stopPodSandbox(), we create it if we end up failing at nsDetachNetdev(). This is somewhat arguable I think, considering currently the error is swallowed but maybe it makes sense to create an event.

---

RDMADeviceDetachFailed - hooks into stopPodSandbox(), this one will be created when we fail at nsDetachRdmadev().

---

NetworkDeviceAttached - again hooks into attachNetdevToNS() but generate this event only on success, ion other words when we get nil from attachNetdevToNS().

---

RDMADeviceAttached - hooks into attachRdmaToNS(), we create this event when we get nil from attachNetdevToNS().

Again, I'm sure this is not the perfect list of the events but I'm happy to hear what you folks think.

[fmuyassarov]

sorry forgot about the resources that will be having these events

1. ClaimPrepareFailed - ResourceClaim
2. DevicePrepareFailed - ResourceClaim
3. NetworkDeviceAttachFailed - Pod
4. NetworkDeviceAttached - Pod
5. NetworkDeviceDetachFailed - Pod
6. RDMADeviceAttachFailed - Pod
7. RDMADeviceAttached - Pod
8. RDMADeviceDetachFailed - Pod