Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DANM 4.0 EP5: Adapting netwatcher to create VLAN and VxLAN interfaces for all APIs #97

Merged
merged 2 commits into from
Jun 18, 2019

Conversation

Levovar
Copy link
Collaborator

@Levovar Levovar commented Jun 12, 2019

Binary is reworked to be able to hold, and run more than one Controllers/Informers.
NetWatcher will hold 3 of them from now on: DanmNet, TenantNetwork, and ClusterNetwork.
It does not matter which API is getting modified, NetWatcher will handle them the exact same way.

NetWatcher will hold 3 of them from now on: DanmNet, TenantNetwork, and ClusterNetwork.
It does not matter which API is getting modified, NetWatcher will handle them the exact same way.
@Levovar Levovar force-pushed the netwatcher_fourdoto branch 15 times, most recently from 8dc2dce to 78a2380 Compare June 18, 2019 08:36
1: Looks like we are patching VLAN and VxLAN IDs as string for TenantNetworks.
This resulted in netwatcher not being able to handle host interfaces, as decoding failed.
We have defined "value" in the Patch struct as RawMessage, which implicitly resulted in always creating "string" patches.
Changed the type to "interface{}" to mimic the official, upstream type, and let json.Marshal take care of creating the appropriate byte[] representation.
2: For some reason ClusterNetworks and TenantNetworks Informers complain during DELETE... but not DanmNet Informer.
Trying to use separate clients and factories per API, maybe it is a multi-treading issue?
Update: turned out these items are tombstone items! We need to handle them gracefully, they might hold our objects.
3: We also unfortunetaly can't avoid separate handlers for each API due to static type correctness.
4: We need to make sure that we only try to create and start an Informer, if its respective API is present in the cluster.
We solve this by doing a "List" first, and only create the Informer if listing was successful.
5: During initial sycnhing TN and CN endpoints received DN objects for some reason
Turns out Informers List during synching. Changing CN and TN List struct to contain the right type solved the issue.
@Levovar Levovar merged commit faad9f6 into master Jun 18, 2019
@Levovar Levovar deleted the netwatcher_fourdoto branch June 21, 2019 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant