Skip to content
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

Update Test 1 / "connectivity_test" to confirm expected endpoints #15

Closed
Tracked by #14
lauralorenz opened this issue Aug 8, 2022 · 4 comments · Fixed by #18
Closed
Tracked by #14

Update Test 1 / "connectivity_test" to confirm expected endpoints #15

lauralorenz opened this issue Aug 8, 2022 · 4 comments · Fixed by #18
Assignees

Comments

@lauralorenz
Copy link
Contributor

Per the KEP, we must test that

Test cluster A can contact service imported from cluster B and route to expected endpoints.

Today, the connectivity_test (which I also refer to as Test 1) confirms the first part ("contact") but does not confirm the second part ("route to expected endpoints"). It does this by confirming that something responded to a request for the Service IP, and that its response contains some text it expects (reference).

This issue is done when this test also gathers the expected pod IPs for the pods in the deployment backing the Service in the source cluster B first*, and then confirming during the connectivity test that it is those IPs and only those IPs that are responding to the Service IP request.

*This should probably be done by collecting the source cluster's Pod.Spec.IPs through the k8s API, and probably be implemented in a separate method that can be used by Test 3 later.

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 6, 2022
@lauralorenz
Copy link
Contributor Author

/assign knee-berts
/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 9, 2022
@k8s-ci-robot
Copy link
Contributor

@lauralorenz: GitHub didn't allow me to assign the following users: knee-berts.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign knee-berts
/remove-lifecycle stale

Instructions 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.

@lauralorenz
Copy link
Contributor Author

/assign lauralorenz
@knee-berts is helping me with this one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants