-
Notifications
You must be signed in to change notification settings - Fork 40
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
end-to-end tests could use external DNS and real authn #2951
Conversation
This reverts commit 7b023b5.
// Nexus's external IP address from the external DNS server. So we'd | ||
// expect Nexus to be up. But that's not necessarily true: external DNS can | ||
// be set up during rack initialization, before Nexus has opened its | ||
// external listening socket. This is arguably a bug, advertising a service |
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.
Should we create an issue to track that? I know the rack/service initialization process could still use some polish.
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.
You mean to track the behavior that Nexus publishes its addresses to DNS before it's opened its listening socket? I'm not clear that's a bug but I'm happy to file an issue to document it and/or have that discussion.
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.
If the expectation is that we should only be adding the DNS records once the service is up then seems we should have an issue tracking that
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.
Thanks!
Building on #2943, this updates the end-to-end tests to use the external DNS server to locate Nexus. They also now use password-based authn using the user created during rack setup, just as a customer will do. (Previously the tests used "spoof" authn with the built-in "test-privileged" user.)
Depends on #2943.