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
fqdn: add fqdn proxy interface #17318
Conversation
8454020
to
acd7c5a
Compare
test-me-please Job 'Cilium-PR-K8s-1.16-net-next' has 3 failures but they might be new flakes since it also hit 1 known flakes: #17060 (83.27) |
acd7c5a
to
f217162
Compare
test-me-please Job 'Cilium-PR-Runtime-net-next' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment |
) | ||
|
||
type FQDNProxy interface { | ||
GetRules(uint16) (restore.DNSRules, error) |
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.
Why does this need to return also an error given that both the DNSProxy
and the MockFQDNProxy
implementations cannot fail?
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.
FWIW the DNSProxy implementation does have error conditions, we just don't hand them back up the stack at the moment. Ultimately I think that the current error condition should not be blocking the implementation of DNS policy so it doesn't make a huge difference where we handle that error, but technically it could be up to the parent functions to handle those errors appropriately (for instance, by outputting them to the endpoint-specific log rather than spamming the global log like the current implementation does).
f217162
to
0ee8a1c
Compare
test-me-please Job 'Cilium-PR-Runtime-net-next' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment Job 'Cilium-PR-K8s-1.16-net-next' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment |
0ee8a1c
to
95d1297
Compare
test-me-please |
) | ||
|
||
type FQDNProxy interface { | ||
GetRules(uint16) (restore.DNSRules, error) |
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.
FWIW the DNSProxy implementation does have error conditions, we just don't hand them back up the stack at the moment. Ultimately I think that the current error condition should not be blocking the implementation of DNS policy so it doesn't make a huge difference where we handle that error, but technically it could be up to the parent functions to handle those errors appropriately (for instance, by outputting them to the endpoint-specific log rather than spamming the global log like the current implementation does).
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, but consider the interface name change proposed by Joe.
95d1297
to
4c9955d
Compare
test-me-please Job 'Cilium-PR-K8s-GKE' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment |
This change adds interface for abstracting away FQDN proxy Signed-off-by: Maciej Kwiek <maciej@isovalent.com>
This change allows for daemon integration tests to run with mock DNS proxy Signed-off-by: Maciej Kwiek <maciej@isovalent.com>
4c9955d
to
b0876c6
Compare
test-me-please |
Hit #16938 in both conformance kind and eks tests |
This change allows us to delete some of the test-specific code in agent and adds an interface for FQDN proxy.