Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Add GKE 1.13 to automated testing suite #169

Merged
merged 5 commits into from
Jun 21, 2019
Merged

Conversation

Crazybus
Copy link
Contributor

@Crazybus Crazybus commented Jun 17, 2019

The only change needed here was to not use goss to directly check if the port is open. With the default install of GKE 1.13 the containers are now being detected as listening on ipv4, when on previous versions it is on ipv6. In reality we only care that it is listening publicly so that services work. So instead the tests have been updated to test this rather than directly looking at the port. This also makes it more likely for the tests to work properly on other Kubernetes providers in the future.

@Crazybus
Copy link
Contributor Author

jenkins test this please

The previous PR test timed out after 30 minutes even though it normally
takes only around 10 minutes. The cluster was actually created in the
end but it was delayed due to current GCP issues.
With the default install on GKE 1.13 the default bound port is now ipv4
instead of ipv6. There is an open issue in goss
goss-org/goss#149 to allow testing for
situations like this where it is listening on both ports.

However the only important thing to test is to make sure that this this
port is listening publicly and that the service actually works.

Also switched the security example to test against the service to make
sure we don't hit the same kibana bug as in #156
This actually should have been removed during the 7.0 release.

It totally still works but won't be actively tested anymore. Since 5.x
uses the same zen discovery configuration as 6.x it will likely stay
working for the whole lifecycle of 6.x too.
Copy link
Contributor

@tylerjl tylerjl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 0.0.0.0 going to be as portable as localhost in the goss tests? I would assume that, if a provider behaved differently, sending requests to localhost would provide the correct v4/v6 resolution independent of what the listener binds to.

@Crazybus
Copy link
Contributor Author

Sorry I hid the in-depth reasoning in one of the git commits: 1292370.

The issue with goss right now is that it can't properly handle situations where a port is listening on tcp4 and tcp6 addresses goss-org/goss#149. The way that it is being detected means that it only works for one. So even though making a http request to 0.0.0.0 works, checking tcp4:0.0.0.0 is open will fail.

But your point is still valid for an ipv6 only environment. I think the most portable option would be to.

  1. Hit localhost when testing the the / endpoint.
  2. Do a test against the service for any cluster related tests (checking health green)

That way ipv4/ipv6 is being left out of it altogether. PR incoming with these changes.

@Crazybus Crazybus merged commit 6f97893 into master Jun 21, 2019
@Crazybus Crazybus deleted the friday_the_thirteenth branch June 21, 2019 07:10
Crazybus added a commit that referenced this pull request Jun 21, 2019
This makes sure that:

1. The tests work in ipv4 and ipv6 environments
2. Testing the service endpoint makes sure that the listening address is
properly configured to allow traffic

Addresses: #169 (review)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants