OVN: use config file via ConfigMap rather than environment variables#333
Conversation
|
You should squash #335 into this |
|
This is a better way to do things, for sure. However, we need to add something to ovnkube that causes it to exit on configuration changes. |
oops, too late. needs-rebase now |
|
/test e2e-aws-ovn-kubernetes |
|
/test e2e-aws-ovn-kubernetes |
|
Two small changes, otherwise looks fine. |
|
@squeed PTAL |
|
/test e2e-aws |
|
Those test failures are not the expected set of failures for ovn-kube. Something is wrong. You'll have to dig in a bit further. |
|
/test e2e-aws-ovn-kubernetes |
|
@squeed didn't spot anything (still not sure what to look for or where) so I ran the test again. |
|
Huh... something is weird with the ingress operator: I don't think this is an ovn problem. /test e2e-aws-ovn-kubernetes |
|
/test e2e-aws-ovn |
2 similar comments
|
/test e2e-aws-ovn |
|
/test e2e-aws-ovn |
|
/retest |
|
/test e2e-aws-ovn |
|
It does seem like the MTU is problematic. Can you check to see if the MTU is correctly respected by all of the interfaces? Perhaps the gateway code hard-codes it when it shouldn't. |
|
Yes, scanning the gateway code shows that it doesn't seem to consume mtu @dcbw |
|
@squeed, @dcbw, whatever is happening here is not happening in other PRs. The mtu is generally handled properly. This might be a corner case. In the spirit of race conditions as we have seen in not getting the correct number of masters, is it possible that the sll certs are not set by the time they are used? The problem discussed in the f2f was in host networking ssl between ovs/ovn components. |
|
My evidence for this is that the control plane seems to come up fine, but the openshift-apiserver (a non-hostnetwork component) times out when trying to write a response back to the kube-apsierver (which is hostnetwork). Looking at the gateway code, I see that the interface created does not have the MTU passed. Get what I'm saying? Would you mind checking to see if I'm right? If not, can you please spin up a cluster for me and I can check? |
|
@squeed Yes I get what you are saying. Why does that happen in PR 333 and not happen in other PRs? What you are asserting should have wide spread impact. The analysis from the f2f showed an ssl problem accessing sdb:9642 using host networking. The connection was established and ssl failed. I am spinning up a cluster, I'll let you know when it is ready. |
|
@squeed cluster didn't come up, bad token. Trying again. |
Configure ovnkube using a config file passed by the ovnkube-config configMap and mounted into the container. SDN-498 Allow overriding MTU in ovn-kubernetes https://jira.coreos.com/browse/SDN-498 The mtu is passed in the configmap. bug 1779105 https://bugzilla.redhat.com/show_bug.cgi?id=1779105 SDN-456 OVN: use config file via ConfigMap rather than environment variables https://jira.coreos.com/browse/SDN-456 Signed-off-by: Phil Cameron <pcameron@redhat.com>
|
/test e2e-aws-ovn |
|
/retest |
|
/test e2e-aws-ovn |
|
@pecameron: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. |
|
/test e2e-gcp |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dcbw, pecameron 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 |
Configure ovnkube using a config file passed by the ovnkube-config
configMap and mountedinto the container.
SDN-456
https://jira.coreos.com/browse/SDN-456
Signed-off-by: Phil Cameron pcameron@redhat.com