USHIFT-2226: Test Multus - Bridge CNI#3137
USHIFT-2226: Test Multus - Bridge CNI#3137openshift-merge-bot[bot] merged 4 commits intoopenshift:mainfrom
Conversation
|
@pmtk: This pull request references USHIFT-2226 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@pmtk: GitHub didn't allow me to request PR reviews from the following users: pmtk. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test ? |
|
@pmtk: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test metal-periodic-test metal-periodic-test-arm |
|
@pmtk: This pull request references USHIFT-2226 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.16.0" version, but no target version was set. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
dhellmann
left a comment
There was a problem hiding this comment.
This looks good. One suggestion about a potential race condition, but I see you're trying to work around that so I'll leave it up to you and other reviewers to decide how risky it is.
There was a problem hiding this comment.
Using the same interface for both tests might be a little brittle, especially if we find a race condition. Can we use separate interfaces to avoid that?
There was a problem hiding this comment.
Yes, though it'll need two (or single templated) NetworkAttachmentDefinition and Pod manifests.
We'll have similar problem with ipvlan / macvlan tests, because:
A single master interface can not be enslaved by both macvlan and ipvlan. (src)
Perhaps we want to add more interface to the VM to avoid that?
There was a problem hiding this comment.
Would we need more than 2? The bridge test doesn't need a new one, right?
There was a problem hiding this comment.
No, bridge plugin doesn't have this exclusivity rule. Other solution is to (probably) reboot the host after the test, so the other *vlan can enslave main interface
There was a problem hiding this comment.
Which approach seems like it will be most reliable?
There was a problem hiding this comment.
I don't have data on that, but adding two nics will be faster (if we keep random order of the tests, then we'll have two reboots).
There was a problem hiding this comment.
Adding the extra NICs sounds like a good place to start, then.
There was a problem hiding this comment.
Made changes to the bridge tests. I decided to duplicate the files as we don't have any templating of such sort yet in RF, so it felt like over-engineering and waste of time.
Regarding the two interfaces for macvlan/ipvlan - that's for another PR(s).
c5e9038 to
7cd55fb
Compare
7cd55fb to
dd38d86
Compare
dhellmann
left a comment
There was a problem hiding this comment.
You've addressed my comments, so I'm happy with this version. I had one philosophical question inline, but it shouldn't block merging this.
You have listed other reviewers, so I'll wait to lgtm to give them a chance to review it.
| *** Test Cases *** | ||
| Pre-Existing Bridge Interface | ||
| [Documentation] Test verifies if Bridge CNI plugin will work correctly with pre-existing interface. | ||
| [Setup] Run Keywords |
There was a problem hiding this comment.
You don't need to change it, but I'm curious why there are so many individual keywords in the setup for this case. Why not include them in the test body, or write a separate keyword?
There was a problem hiding this comment.
Why not include them in the test body
I was being literal - test setup in [Setup]
or write a separate keyword?
I didn't like how this requires a jump to different location in the file - this way everything is single place.
So I think I just felt like it :D It's not perfect though, this keyword (in this or future PR) is maxing out the length, but separate keyword was "context jump" and writing general function for both Bridge tests was quite ugly and required some mental processing on what happens with which arguments.
There was a problem hiding this comment.
It can definitely be hard to find a balance between inline and separate code blocks. That max keyword aspect to the linter is a nudge towards what the linter author thought we should be doing, but there have definitely been cases where we overrode the rule. Maybe we should have written more of those cases in Python? I don't know. As I said, there's no need to change anything here, I was just curious about the evolution of the code.
There was a problem hiding this comment.
Maybe we should have written more of those cases in Python?
Perhaps, but python function don't support so great support for log.html. We'll see in the future
|
Regarding of CNI config in net-attach-def, it looks good to me. |
|
LGTM |
| - name: hello-microshift | ||
| image: quay.io/microshift/busybox:1.36 | ||
| command: ["/bin/sh"] | ||
| args: ["-c", "while true; do echo -ne \"HTTP/1.0 200 OK\r\nContent-Length: 16\r\n\r\nHello MicroShift\" | nc -l -p 8080 ; done"] |
There was a problem hiding this comment.
Do we want to add "sleep" here not to burn CPU?
There was a problem hiding this comment.
This doesn't spin furiously - nc blocks until a client arrives, so the loop has a many iterations as many GETs.
| - name: hello-microshift | ||
| image: quay.io/microshift/busybox:1.36 | ||
| command: ["/bin/sh"] | ||
| args: ["-c", "while true; do echo -ne \"HTTP/1.0 200 OK\r\nContent-Length: 16\r\n\r\nHello MicroShift\" | nc -l -p 8080 ; done"] |
There was a problem hiding this comment.
Do we want to add "sleep" here not to burn CPU?
There was a problem hiding this comment.
This doesn't spin furiously - nc blocks until a client arrives, so the loop has a many iterations as many GETs.
| ${PREEXISTING_BRIDGE_POD_NAME} test-bridge-preexisting | ||
| ${PREEXISTING_BRIDGE_IP} 10.10.1.10/24 | ||
|
|
||
| ${NS} default |
There was a problem hiding this comment.
Is there a special reason we're not using a dedicated namespace for this test?
There was a problem hiding this comment.
Not really, let me have a look
| ... Oc Delete -f ${nad} | ||
| Command Should Work ip link delete ${if} | ||
|
|
||
| Curl Pod Over Local Interface |
There was a problem hiding this comment.
Nit: Curl is an implementation detail. Should we call it Connect Pod or something?
There was a problem hiding this comment.
Connect To Pod Over Local Interface? Because in future PRs there's Curl Pod From The Hypervisor so we need to be more specific
| Interface Should Not Exist | ||
| [Documentation] Verifies that network interface does not exist. | ||
| [Arguments] ${if} | ||
| ${stdout} ${rc}= Execute Command | ||
| ... ip link show ${if} | ||
| ... sudo=True return_rc=True | ||
| Should Be Equal As Integers ${rc} 1 |
There was a problem hiding this comment.
Feels as if we would benefit from Command Should Not Work keyword.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ggiguash, pmtk The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@pmtk: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
No description provided.