0285bfe42e
What/Why I did: Issue1: By setting up of ipvlan interface in interface-config.sh we are not tolerant to failures. Reason being interface-config.service is one-shot and do not have restart capability. Scenario: For example if let's say database service goes in fail state then interface-services also gets failed because of dependency check but later database service gets restart but interface service will remain in stuck state and the ipvlan interface nevers get created. Solution: Moved all the logic in database service from interface-config service which looks more align logically also since the namespace is created here and all the network setting (sysctl) are happening here.With this if database starts we recreate the interface. Issue 2: Use of IPVLAN vs MACVLAN Currently we are using ipvlan mode. However above failure scenario is not handle correctly by ipvlan mode. Once the ipvlan interface is created and ip address assign to it and if we restart interface-config or database (new PR) service Linux Kernel gives error "Error: Address already assigned to an ipvlan device." based on this:https://github.com/torvalds/linux/blob/master/drivers/net/ipvlan/ipvlan_main.c#L978Reason being if we do not do cleanup of ip address assignment (need to be unique for IPVLAN) it remains in Kernel Database and never goes to free pool even though namespace is deleted. Solution: Considering this hard dependency of unique ip macvlan mode is better for us and since everything is managed by Linux Kernel and no dependency for on user configured IP address. Issue3: Namespace database Service do not check reachability to Supervisor Redis Chassis Server. Currently there is no explicit check as we never do Redis PING from namespace to Supervisor Redis Chassis Server. With this check it's possible we will start database and all other docker even though there is no connectivity and will hit the error/failure late in cycle Solution: Added explicit PING from namespace that will check this reachability. Issue 4:flushdb give exception when trying to accces Chassis Server DB over Unix Sokcet. Solution: Handle gracefully via try..except and log the message. |
||
|---|---|---|
| .. | ||
| per_namespace | ||
| share_image | ||
| arp_update_vars.j2 | ||
| buffers_config.j2 | ||
| cbf_config.j2 | ||
| config-chassisdb.service.j2 | ||
| config-setup.service.j2 | ||
| database.service.j2 | ||
| dhcp_relay.service.j2 | ||
| docker_image_ctl.j2 | ||
| iccpd.service.j2 | ||
| init_cfg.json.j2 | ||
| kube_cni.10-flannel.conflist | ||
| lldp.service.j2 | ||
| lldp.timer.j2 | ||
| manifest.json.j2 | ||
| mgmt-framework.service.j2 | ||
| mgmt-framework.timer | ||
| mux.service.j2 | ||
| nat.service.j2 | ||
| organization_extensions.sh | ||
| p4rt.service.j2 | ||
| packages.json.j2 | ||
| pde.service.j2 | ||
| pmon.service.j2 | ||
| pmon.timer | ||
| qos_config.j2 | ||
| radv.service.j2 | ||
| restapi.service.j2 | ||
| sflow.service.j2 | ||
| snmp.service.j2 | ||
| snmp.timer | ||
| sonic_debian_extension.j2 | ||
| sonic_version.yml.j2 | ||
| sonic-delayed.target | ||
| sonic.target | ||
| swss_vars.j2 | ||
| tacacs-config.service | ||
| tacacs-config.timer | ||
| telemetry.service.j2 | ||
| telemetry.timer | ||
| updategraph.service.j2 | ||