nokia / danm

25%

master: 44%

LAST BUILD ON BRANCH netwatcher_fourdoto

branch: netwatcher_fourdoto

CHANGE BRANCH

x

Reset

• netwatcher_fourdoto
• add-copyright-headers
• akraino-install-guide-link
• alloc6_api
• api_group_migration
• binaries
• category_all
• central_ipam_fixes
• cmd_intro
• cni_del_fix
• cni_res_fix
• cnidel_steroid
• cnidel_uts
• concurrent_confman
• configure_naming
• damn-danm
• deploy-guide
• device_handling_fixes
• dis_dad
• dnet_apitype_fix
• dummy_cosmetics
• dummy_encsa
• fix_add_gc
• fix_confman_core
• fix_ip_delegation
• fix_netype_bug
• fix_none_ip
• fixin_uts
• formatting
• go_12_9
• intel_dpdk
• intel_vf_wa
• ip6conf_for_none
• ipam_for_everyone
• ipam_prefix_change
• ipam_store_last_ip
• ipam_uts
• ipv6_cudo
• k8s_1.21_fix
• logo-with-name
• master
• metacni_fourdoto
• netadmit_uts
• netdel_ut
• netwatcher_healthcheck
• netwatcher_modify
• netwatcher_nad
• networktype_separation
• new_apis
• outage
• perf_fix
• pod_id_to_ep
• prefix_fix
• readme_facelift
• route_device_fix
• route_man_fix
• rutas
• set_ndisc_noti
• slack-links
• store_client
• svcw_update_fix
• svcwatcher_fourdoto
• svcwatcher_healthcheck
• svcwatcher_ns
• svcwatcher_update_eps
• syncher_ut
• tconf_hook_ut
• tenantnet_setup
• typo-correction
• uid_weeding
• update_delegation
• v3.2.0
• v3.3.0
• v4.0.0
• v4.1.0
• v4.2.0
• v4.2.0-RC1
• v4.2.0-rc2
• v4.2.0-rc3
• v4.2.1
• v6_alloc
• v6_stat
• validate_max_netmask
• validate_new_apis
• validation_type_change
• versioning
• webhook
• wording/changes
• y_u_no_free

Build # 487

Build Type

push

travis-ci

Committed by Levovar

Commit Message

Multiple problems occured during testing.

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.

Run Details

541 of 2177 relevant lines covered (24.85%)

6.32 hits per line