xds/internal/server: stop using a fake xDS client in listenerWrapper tests #6700
Conversation
| case <-sCtx.Done(): | ||
| } | ||
|
|
||
| // Configure the management server with a good update that does not contain |
There was a problem hiding this comment.
Nit here and top level: can you explain what makes this update good? (i.e. matching host and port of listener).
|
|
||
| // Configure the management server with a listener resource that does not | ||
| // match the address to which our listener is bound to. | ||
| resources.Listeners = []*v3listenerpb.Listener{e2e.DefaultServerListener(host, port+1, e2e.SecurityLevelNone, route1)} |
There was a problem hiding this comment.
Is getting a response from the management server with a host and port that don't match a listeners host/port a common use case? How does it match it up mechanically? A user configures server to listen on certain ports and the management server to specify the logic of the listeners accepted on certain ports?
| oldRBAC := envconfig.XDSRBAC | ||
| envconfig.XDSRBAC = true | ||
| defer func() { | ||
| envconfig.XDSRBAC = oldRBAC | ||
| }() |
There was a problem hiding this comment.
Why does this need to turn on this env var? Is it so this conditional doesn't hit:
? If so, can you briefly mention why this is turned on. The test above does not turn it on.| select { | ||
| case <-ctx.Done(): | ||
| t.Fatalf("timeout waiting for the ready channel to be written to after receipt of a good Listener update") | ||
| t.Fatalf("Timeout waiting for the ready channel to be written to after receipt of a good Listener update") |
There was a problem hiding this comment.
It seems like you don't need inline route configuration to trigger ready, just no rds specified in filter chains? Can you test no inline route update/no specified rds name too? I think should become ready too.
| select { | ||
| case <-ldsNamesCh: | ||
| default: | ||
| } | ||
| select { | ||
| case ldsNamesCh <- req.GetResourceNames(): | ||
| default: | ||
| } |
There was a problem hiding this comment.
Selective sends and selective receives feel scary? I know you explained this in other pr, but why do you need this selectivity? Also, if you receive from the channel, why do you immediately selectively send on it, will it even be possible for another concurrent send to occur in between?
This is in prep for xDS generic API changes for the server side.
#resource-agnostic-xdsclient-api
RELEASE NOTES: none