forked from k8snetworkplumbingwg/multus-cni
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Sync master with upstream #6
Open
cruizen
wants to merge
74
commits into
platform9:master
Choose a base branch
from
k8snetworkplumbingwg:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the CNI request failure, multus-cni prints out cmdArgs. In all cases, except for debug printing, this is done with %s and a special printing function. However, the handleCNIRequest is an exception for some reason. That leads to unintelligible error messages in case of CNI request failures (severely abridged): CmdAdd (shim): CNI request failed with status 400: '&{ContainerID:<id> Netns:/var/run/netns/<uuid> IfName:eth0 Args:<args> Path: StdinData:[125 121 111 117 114 32 97 100 118 101 114 116 105 115 101 109 101 110 116 32 99 111 117 108 100 32 98 101 32 104 101 114 101 125 ... another 650 numbers ]} ContainerID:"<id>" Netns:"/var/run/netns/<uuid>" IfName:"eth0" Args:"<args>" Path:"" ERRORED: error configuring pod ... printCmdArgs() should be used for this case as well to avoid huge hardly readable logs. At the same time, the content of cniCmdArgs is always appended to the error twice as seen in the example above. The first time by the HandleCNIRequest and another time by the handleCNIRequest. Same for the HandleDelegateRequest path. Just removing the prefixing from the lower level handlers while keeping higher level ones. The 'ERRORED' part migrated to the higher level handler functions to preserve the overall look of the error. Signed-off-by: Ilya Maximets <[email protected]>
Bumps google.golang.org/protobuf from 1.31.0 to 1.33.0. --- updated-dependencies: - dependency-name: google.golang.org/protobuf dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
server: More concise error messages.
interface name should not be limited to DNS-1123 label format. instead validate interface name if provided in pod network annotation in a similar manner as iproute2[1]. this will allow to request interface names such as: "uplink_p0" [1]https://github.com/iproute2/iproute2/blob/11740815bfe69d6ee2cad7c608a8edc70147209a/lib/utils.c#L832 Signed-off-by: adrianc <[email protected]>
…les/google.golang.org/protobuf-1.33.0 Bump google.golang.org/protobuf from 1.31.0 to 1.33.0
This is to support the new MTU field in cni network results Signed-off-by: Sebastian Sch <[email protected]>
Signed-off-by: Moshe Levi <[email protected]>
Signed-off-by: Moshe Levi <[email protected]>
Signed-off-by: Vasilis Remmas <[email protected]>
Enforce termination message policy on all platform pods
Bump cni and network-attachment-definition-client to support MTU
Bumps [golang.org/x/net](https://github.com/golang/net) from 0.17.0 to 0.23.0. - [Commits](golang/net@v0.17.0...v0.23.0) --- updated-dependencies: - dependency-name: golang.org/x/net dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
Multus v3.9.3 has `--multus-master-cni-file-name` flag to specify the name of a primary CNI config file. https://github.com/k8snetworkplumbingwg/multus-cni/blob/v3.9.3/images/entrypoint.sh#L22 In Multus v4.0.2, the thin plugin has the flag defined, but it is not read and so does not have effect. This pull request fixes the problem by making the thin plugin correctly handles `--multus-master-cni-file-name` flag. Fixes #1226 Signed-off-by: Hidehito Yabuuchi <[email protected]>
…les/golang.org/x/net-0.23.0 Bump golang.org/x/net from 0.17.0 to 0.23.0
rename conf param, 'defaultnetworkfile' to 'readinessindicatorfile'
Fix defaultnetworkfile in unit test
deleteDefaultGWResult() may create 'routes:null' in CNI cache file and it causes nil pointer access at addDefaultGWCacheBytes(). This code change prevents deleteDefaultGWResult() to generate 'routes:null' in cache file.
Fix CNI cache update function to prevent nil access
thin plugin: Handle `--multus-master-cni-file-name` flag
Signed-off-by: Vasilis Remmas <[email protected]>
This modifies the behavior on CNI DEL for the thick plugin to just check once for API readiness, as opposed to waiting.
Thick plugin should not wait for API readiness on CNI DEL
Fixes: #1281 Signed-off-by: Adrian Vladu <[email protected]>
Change Validation of interface name
add support for Dynamic Resource Allocation
APIReadyCheckFunc is used only in api, hence it can be decapitalize to make its scope only in this package. This fix changes its scope. In addition, api.APIReadyCheckFunc seems to be redundant so the name is changed. Change the comment to fit to golang style, too.
Not exposed APIReadyCheckFunc to outside of package
arm64: build image for arm v8
create multus kubeconfig for in case of non auto flag.
Updates to use CreateNetworkStauses from net-attach-def client, bump to v1.7.1
Signed-off-by: Ahmad Zolfaghari <[email protected]>
Doc: change install from file to url in readme, how-to-use
Disabled DRA test temporarily
This fixes the default:true for multiple interface returns from CNI for cluster default network, where all interfaces in that return were marked as default:true in the network-status
Bumps net-attach-def client library to v1.7.2
Previous version didn't account for accounts for the sandox interfaces when reporting the interfaces in the network-status annotation when calculating the default:true interface
Bumps net-attach-def client to v1.7.3
Which improves backwards compatibility for network-status in latest updates to the client library, especially related to Calico. See also: k8snetworkplumbingwg/network-attachment-definition-client#72
Updates net-attach-def client library to v1.7.4
From the release notes: > This release contains a fix related to the determination of the default interface, e.g. setting the default parameter to true in the network-status annotation based on the presence of a gateway in the CNI ADD success result ips.gateway and makes the determination of the default based on the first interface that has an associated value of gateway (using the interface index in the ips element in the CNI ADD success result). > This provides flexibility especially in CRI-O which uses the first interface and IP addresses for the pod.IP in Kubernetes, therefore. Containerd functionality is unchanged in that it uses the value for the IP addresses specifically > It's worth noting that CNI ADD success results which do not contain any interfaces will be discarded in this determination of the default, therefore it's recommended to set one with an associated gateway if aiming to have it be noted as the default. See also: https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/releases/tag/v1.7.5 k8snetworkplumbingwg/network-attachment-definition-client#73
Update net-attach-def client library to 1.7.5 for cri-o functionality
clean up go.mod, get rid of client-go v1.5.2
Signed-off-by: smoshiur1237 <[email protected]>
Support go 1.22 and 1.23 build to fix CVE
If Multus plugin gets a DEL request, but the API Server is down (e.g. via 'crictl rmp'), the call takes so long, it actually never finishes. This prevents CRI-O from deleting the Pods.
Thin plugin: don't wait too long for an answer from API Server
It was explained to me that informers are almost always are more efficient, and in most cases will work, but a live lookup is appropriate after a number of failures. This happens only on the retry portion, so we're still getting the benefits of informers, but, on a retry situation, we don't get a cache miss. Additionally, changes out use of cache get on this, since it already bails out before it on CNI DEL.
always attempt a live pod get on miss to confirm its really not there
adds context to GetPodAPILiveQuery
This change supports up to date CNI 1.1 command, GC and STATUS for cluster network.
This code changes CNI's GC command argument. Previously it just passes from parent CNI runtime, however, it may causes unexpected resource deletion if one CNI plugin is used in both cluster network and net-attach-def. This change generates valid attachments from multus CNI cache and passed to delegate CNI plugin.
Shubhamag12
approved these changes
Jan 10, 2025
CNI 1.1.0 support
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.