Conversation
|
Thanks @ericgribkoff
It looks a bug regardless of the _WAIT_FOR_URL_MAP_PATCH_SEC timeout config changes previously. We should return early when successful. I will fix in the current test framework, similar to what you've done here. |
Actually it looks this verification was on purpose. It should verify that after deleting first set of map+tp+fr, traffic still goes to the original backends, but, we do not know whether this was because TD didn't propagate, or because they propagated and grpc is doing the right thing. So, we waited long enough and assume it is propagated, therefore we know that creating the second api listener is safe. And yes, the verification should probably be polling for TD propagation instead of waiting for their SLA. |
|
@ericgribkoff can I have write permission to this branch, I have changes ready to complete this PR. |
|
@YifeiZhuang The "allow edits by maintainers" box is already checked (https://screenshot.googleplex.com/AYUDXfQMuyzHpei). Is there something else you'd like me to enable? |
hmmm, i don't know. I switched to #27534, just to be faster. |
|
This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 30 days. It will be closed automatically if no further update occurs in 7 day. Thank you for your contributions! |
This ports the api listener test case to k8s. I noticed that the current implementation of this test case in
run_xds_tests.pyseems to have what amounts to an unconditional 10 minute wait here - I'm not quite sure what's going on with theverify_attemptscalculation in Python, as it seems to come out to equal 60, which I can only reproduce in a repl with int(_WAIT_FOR_URL_MAP_PATCH_SEC / (10.0 * qps) * qps), e.g., with a floating point value for_NUM_TEST_RPCS. Regardless, from the logs it's clearly executing the loop 60 times at 10 seconds per call, resulting in the overall test case typically running 18-20 minutes. Since this isn't actually doing anything but (attempting) to wait for TD propagation - and we can't tell the difference between not-having-propagated and the test passing - I just shortened this loop considerably here. We should be able to properly verify that the propagation has occurred via the CSDS service, which is left as a TODO.I did not have time to finish the forwarding-rule* or metadata-filter test cases, so just sending what I have here.