futurewei-cloud / alcor-int Goto Github PK

The networking namespace passed from k8s to mizarmp-CNI is “/proc/14705/ns/net”, which is in the format of “/proc/PID/ns/net”. It is based on AWS container runtime. It is unique and it is an acceptable format. Unfortunately, the current approach of taking only the last part of the string (that is “net”) will not work because:

1. It is not unique for different endpoints running on the same host
2. It doesn’t align with the ip netns format with our initial thinking based on our familiar container runtimes

current implementation of cni plugin stops the Add op if it fails to query port status, or the response code is not 200. It may make sense to categorize some errors as retry-on-site, and immediately give it retry, in a hope the retry overcome the transient problem and get response body with 200 status code.

This is not high priority issue, as CNI plugin would be invoked by CRI periodically in case of Add operation failure.

Following the below instruction from k8s cluster setup wiki:

5. Build a docker container for controller and push to registry
   ./scripts/build.sh
   For Mac, run the corresponding commands instead, that is:
   brew install maven
   brew tap AdoptOpenJDK/openjdk
   mvn clean
   mvn compile
   mvn install <----- got below test errors

[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] AlcorControllerAppTest.contextLoadsTest » IllegalState Failed to load Applicat...
[ERROR] GoalStateProvisionerClientTest.greet_messageDeliveredToServer:96 » NullPointer
[ERROR] DataCenterConfigLoaderTest.machineConfigFileLoadTest:29 » NullPointer
[ERROR] DebugControllerTest.shouldReturnDefaultMessage » IllegalState Failed to load A...
[INFO]
[ERROR] Tests run: 13, Failures: 0, Errors: 4, Skipped: 0

This error could be due to different JDK version used in mac vs linux.

current cni plugin puts local persistent store under /etc/mizarmp_ports/. These kind of dynamic data seems better under /run (or /var/run).

current cni plugin removes local persistent data for whole sandbox on deletion. this could be a problem if there are multiple nics for a pod, like a multi-home pod setup by multus-cni.