-
Notifications
You must be signed in to change notification settings - Fork 175
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
DCOS-48854: Upgrade Elastic base-tech to 6.6.1. #2976
Conversation
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.
Sounds good.
Thanks for the review @rishabh96b. I'll take a look into those test failures. |
And healthcheck credentials configured.
This commit introduces no functional changes. It is an aesthetic refactoring.
This fixes the TLS test, so we can remove the "skip" annotation.
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, @mpereira! LGTM as far as I can tell. Also, I noticed that test_upgrade.test_xpack_security_enabled_update_matrix
is failing in TC.
Thanks for taking a look @akirillov! I'm looking into that failure now. It's related to the latest released version in the Universe right now not being ES5 anymore (due to the recent 6.3.2 release). Should have that fixed shortly. |
All green. Merging. |
This PR is only for the base-tech version bump, and changes required to support it. After the PR is merged to master, a stable branch for the release will be created (as per our release process).
This PR started with the upgrade of the Elastic base-tech to version 6.1.1: 4ef375d
This uncovered two important test failures:
test_sanity.test_security_toggle_with_kibana
test_tls.test_tls_recovery
An example can be seen in this TC build.
Fixing
test_sanity.test_security_toggle_with_kibana
The issue here was that a Kibana instance with X-Pack Security disabled was failing to be installed due to a failing healthcheck. Kibana's healthcheck with a disabled X-Pack Security used to hit
/service/kibana
(for a Kibana service named "kibana"). It looks like the root cause is a change to Kibana that was incorporated somewhere in between our latest released version (6.3.2) and 6.6.1.The fix is in 4271515.
Fixing
test_tls.test_tls_recovery
This one was a bit more involved. The issue here was related to a change in Elasticsearch that caused TLS-enabled clusters with a "basic" license to not be able to have nodes leaving and re-joining the cluster. It is related to this Elasticsearch issue.
The solution involved enabling the trial license and setting up passwords and credentials on TLS tests: 407e139
After those two failures were fixed, another one surfaced:
test_tls.test_crud_over_tls
.Fixing
test_tls.test_crud_over_tls
This popped up because now the Elasticsearch cluster for TLS tests is configured with passwords, so HTTP requests to the Elasticsearch cluster needed to include basic HTTP credentials. This was fixed here: 47aaa72
With all tests passing, while doing some experiments, I noticed that a test that was disabled a few months ago could be fixed
test_tls.test_kibana_tls
.On Kibana 6.6.1, probably due to the aforementioned change, the actual endpoint on "X-Pack Security"-enabled Kibanas (
/service/kibana/login
) "works". It returns an HTTP 200 because it successfully hits the Kibana server through Adminrouter, which returns the Kibana log in page. However, it is still impossible to actually log into Kibana through the service link due to DCOS-46801.The fix for this is in 1f499cb.
This PR is best reviewed commit-by-commit. There's one with a big diff (bb89d42) but its changes are aesthetic, with no functionality changes.