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

TESTS: Use File Based Discovery in REST Tests #34560

Merged

Conversation

original-brownbear
Copy link
Member

* For 7.0 use file based discovery in REST tests
* Relates elastic#33675
@original-brownbear original-brownbear added >test Issues or PRs that are addressing/adding tests v7.0.0 :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. labels Oct 17, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@original-brownbear
Copy link
Member Author

@DaveCTurner I hope this is what we want here :)
Also, should I do anything about pre-7.x here? (I guess that would require using the file based discovery plugin in older versions?)

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

File-based discovery is available without a plugin in 6.x so I think once 6.5.0 is released we can do this (in master) without worrying about versions. We should wait.

Also, with this change I think the whole concept of a "seed" node can go away.

Also, with this change I think we can undo the changes in #27344 and go back to a more reasonable setting for minimum_master_nodes.

@DaveCTurner
Copy link
Contributor

Also, should I do anything about pre-7.x here? (I guess that would require using the file based discovery plugin in older versions?)

I'm not sure - how easy is it to install a plugin for these tests? If it's easy, I think we should try and make an equivalent change to 6.x that does indeed involve installing the discovery-file plugin before starting these nodes.

@original-brownbear
Copy link
Member Author

@DaveCTurner I think there is logic that helps with installing plugins in this code but I would need to research this a little to see how tricky it is to actually use it.
Are you suggesting otherwise generally blocking the work here until 6.5.0 is out?

@DaveCTurner
Copy link
Contributor

Are you suggesting otherwise generally blocking the work here until 6.5.0 is out?

Yes.

@DaveCTurner
Copy link
Contributor

Are you suggesting otherwise generally blocking the work here until 6.5.0 is out?

Yes.

Wrong again! I thought we tested master against 6.4 as well as 6.x but apparently not. This PR can proceed, sorry.

@original-brownbear
Copy link
Member Author

@DaveCTurner no worries :) I'm back on it then

@original-brownbear
Copy link
Member Author

@DaveCTurner alright, that was a confusing one (sorry for missing that 6.x also supports the file based discovery out of the box :D) => Removed the condition for the version now. Take another look when you have a sec :)

@original-brownbear
Copy link
Member Author

@DaveCTurner argh :D see Jenkins log ... we do run against 6.4.x-snapshot => back to waiting it out here? :)

@original-brownbear
Copy link
Member Author

@DaveCTurner alright back to plan A as discussed: Made it only use file based discovery for 6.5+ now. Should be good for another review :)

@original-brownbear
Copy link
Member Author

@DaveCTurner finally green :)

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

Neat! Can we lose the start-one-node-then-start-the-rest pattern for 6.5.0+ clusters? I asked for a handful of minor changes too.


nodes.forEach { node ->
Collection<String> unicastHosts = new HashSet<>()
nodes.forEach { otherNode ->
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to be nested? Could we calculate it once up-front and then write all the hosts files?

Copy link
Member Author

Choose a reason for hiding this comment

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

Wouldn't we want to not have self-references in these (I guess it doesn't matter), but in that case we actually need additional code to account for the one self-reference that will return null in that loop.
I just figured this was the shortest solution? :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, more seed node weirdness. I think you should up-front call unicastTransportUri(node, null, project.ant) in order to read the transport address of every node, and then put all of them into all of the unicast_hosts.txt files. It's normal for all the nodes to have the same list of unicast hosts, even though one of them refers to itself.

@@ -703,6 +724,7 @@ class ClusterFormationTasks {
}
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

You could make this PR 4% smaller by removing this line again ;)

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

(copied from previous review): Also, with this change I think we can undo the changes in #27344 and go back to a more reasonable setting for minimum_master_nodes.

@original-brownbear
Copy link
Member Author

original-brownbear commented Oct 20, 2018

@DaveCTurner alright all handled I think:

The waiting for the seed node was easy to fix functionally in 391a8a6 (just don't add the task dependency to new version nodes). I didn't refactor the code for it a great deal because of the last point below

The precomputing the unicast hosts and setting [] for the unicast hosts in the missing spots is in 2052e0c

The situation with the minimum master nodes setting I don't think I can easily fix here. For the BwC nodes this will still spell trouble because we're still using the old way of setting the unicast hosts to the first node for those and nothing has changed for them? => I didn't make any changes to that and also figured there wasn't too much point in a larger code change to separate the paths for older than 6.5 and newer than 6.5 until we had a plan for that. Maybe add a new issue (or bullet point in the existing one :)) for that and look for a clean refactoring and fix for the pre-6.5 situation there?

@original-brownbear
Copy link
Member Author

Jenkins test this

@original-brownbear
Copy link
Member Author

@DaveCTurner looks like GH finally refreshed :) This should be good for another review now.

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

I'm happy with this (except the longer timeout, see comment). However CI is not. We looked into it together and suspected that there's something wrong with how the discovery plugin tests work. If so, and if it fixes it, I'd be ok with reinstating the discovery.zen.ping.unicast.hosts lists in those cases and then following up with a proper fix as a separate PR.

@@ -131,7 +137,7 @@ class ClusterConfiguration {
* condition is executed.
*/
@Input
int nodeStartupWaitSeconds = 30
int nodeStartupWaitSeconds = 120
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather not do this - I think there's something wrong with the discovery plugin tests.

@original-brownbear
Copy link
Member Author

@DaveCTurner it seems the normal discovery mechanism interfering (or rather it not doing so) wasn't the issue here.
We're making all the nodes return null for their transport endpoint in

unicastTransportUri = { seedNode, node, ant -> return null }
=> still at it.
Looking into the changed dependency order now.

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

LGTM

@original-brownbear original-brownbear merged commit 0a85997 into elastic:master Oct 24, 2018
@original-brownbear original-brownbear deleted the rest-tests-file-discovery branch October 24, 2018 15:18
kcm pushed a commit that referenced this pull request Oct 30, 2018
* For `6.5+` use file based discovery in REST tests
* Relates #33675
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Nov 14, 2018
* For `6.5+` use file based discovery in REST tests
* Relates elastic#33675
original-brownbear added a commit that referenced this pull request Nov 15, 2018
* For `6.5+` use file based discovery in REST tests
* Relates #33675
@original-brownbear original-brownbear restored the rest-tests-file-discovery branch January 6, 2021 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >test Issues or PRs that are addressing/adding tests v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants