-
Notifications
You must be signed in to change notification settings - Fork 583
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
Allow the default-route to be empty #553
Conversation
In https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_RNydhVE1Kx54kFQ, section 4.1.2.1.9, " 4.1.2.1.9 “default-route” Default route selection for a particular attachment This optional key with value of type string-array is used to explicitly select which attachment will receive the default route. The value of items in the “default-route” array are intended to be gateways, e.g. an IP address to which packets that do not match any other routes are sent. This key must only be set on one item in the Network Attachment Selection Annotation. This list may be empty. " However en empty list will fail currently; this change accommodates an empty "default-route" by retaining the default route added by the delegate. Signed-off-by: venugopal iyer <venugopali@nvidia.com>
Pull Request Test Coverage Report for Build 245363538
💛 - Coveralls |
Thank you for your PR, @venuiyer ! |
thanks for reviewing, @s1061123! |
Hey @venuiyer -- thanks for the discerning eye against the spec, I appreciate it a lot! I think I'm OK to move forward with accepting the PR, it looks good to me. I'm going to run a manual test against it locally. However, I can't currently recreate the problem under the current code base. Do you mind providing the annotation which caused the problem? Here's a test I ran against Multus (one that's a couple months old honestly)
|
Thanks for checking this; I'll get back on this, please hold off on the merge till then. I think I am missing one change from what I tested with, so let me verify and get back. Thanks! |
Sorry @dougbtv for the delayed response, was caught up on something else. Hopefully, the following is useful info. for this - let me know if that helps and/or I am missing anything..
So, the sriov-conf in my case looks like: cat /etc/cni/net.d/10-sriov_net.conf /etc/cni/net.d/10-sriov_net1.conf { The CRDs are: kubectl describe network-attachment-definitions sriov-stream-net kubectl describe network-attachment-definitions sriov-stream-net-1 And, my pod spec looks like: apiVersion: v1
I want to set the "default-route" to either sriov-stream-net or sriov-stream-net-1 based on the annotation. With the above, I see: kubectl describe pod testpod Warning FailedCreatePodSandBox 8m9s kubelet, k8s-node-08 Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "02239ef434a480e913d8d7666fbea5415a7b73ae18d2bd71a787bbbf125e0066" network for pod "testpod": networkPlugin cni failed to set up pod "testpod_default" network: Multus: [default/testpod]: error setting default gateway: one of Dst.IP, Src, or Gw must not be nil, failed to clean up sandbox container "02239ef434a480e913d8d7666fbea5415a7b73ae18d2bd71a787bbbf125e0066" network for pod "testpod": networkPlugin cni failed to teardown pod "testpod_default" network: delegateDel: error invoking DelegateDel - "sriov": error in getting result from DelNetwork: error reading cached NetConf in /var/lib/cni/sriov with name 02239ef434a480e913d8d7666fbea5415a7b73ae18d2bd71a787bbbf125e0066-net2] This comes from:
With the proposed changed in this PR and the same pod spec: kubectl exec -it testpod -- ip ro with the pod spec changed to : ... annotations: ... kubectl exec -it testpod -- ip ro |
I owe you a replication @venuiyer ! My apologies this got left behind, we had missed a maintainers meeting so I didn't get a review of open PRs in. I haven't forgotten -- thank you for the scenario for me to use! Appreciate it. |
Thanks @dougbtv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! (sorry for the delay)
Thanks @dougbtv !! |
In
https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_RNydhVE1Kx54kFQ,
section 4.1.2.1.9,
"
4.1.2.1.9 “default-route” Default route selection for a particular attachment
This optional key with value of type string-array is used to explicitly select
which attachment will receive the default route. The value of items in the
“default-route” array are intended to be gateways, e.g. an IP address to which
packets that do not match any other routes are sent. This key must only be set
on one item in the Network Attachment Selection Annotation. This list may be empty.
"
However en empty list will fail currently; this change accommodates an
empty "default-route" by retaining the default route added by the
delegate.
Signed-off-by: venugopal iyer venugopali@nvidia.com