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

RFC: Proposal to replace fixtures with docker-compose #35651

Merged

Conversation

alpar-t
Copy link
Contributor

@alpar-t alpar-t commented Nov 16, 2018

This is a non complete example to request feedback on the general
direction before mooing forward with these changes.
It's lacking detect and skip functionality and causes the containers to go up even when they are not needed, but these are workable if we find the general approach ok.

We can easily support random ports with this setup as the Gradle plugin exposes a map of the randomly assigned ports, it's just a matter of passing them to the tests.

The plugin being used is documented here: https://github.com/avast/gradle-docker-compose-plugin

Relates to #34095

This is a non working example to request feedback on the general
direction before mooving forward with thease tools.

We can easily support random ports with this setup as the Gradle plugin
exposes a map of the randomly assigned ports.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

I like the idea. It'd be nice to know:

  1. If docker isn't installed, can we still skip the tests like we do with vagrant?
  2. Is it possible that it'd work on Windows? It looks like Docker has a thing for Windows.

I think a good next thing to check is "how do random ports work?"

* Allows for other subprojects to depend on the project level and not care about the details
* of composeUp
*/
jar {
Copy link
Member

Choose a reason for hiding this comment

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

This seems funky. I think I'd prefer to depend on the task.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't fully convinced either, just wanted to bring it up. Let's do the task it's more straight forward.

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 19, 2018

  1. We can still ski the tests if docker-composed is not installed. By the same means as we do for vagrant, it's just not implemented yet.
  2. This will work on windows. I have used the plugin on windows, and it's documentation said it handles differences gratefully. I know there are some differences when dealing with volumes, I don't remember the specifics, I think it was something like it's possible to mount a single file on Linux but not on Windows - something easy to work around.

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 19, 2018

Thanks for taking a look @nik9000 I'm glad you like it.

I made changes to show how remote ports could work.
I'm getting test failures now, but these don't seem to be related. I'll have to check if I also get them on master.

I'm thinking of pulling it into a plugin, to avoid repetition throughout the build.
Detecting docker-compose would be part of that and I think we can figure out from the plugin what needs to be disabled for the most part. I'll look at that next.

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

I love the idea.

One thing that bothers me a little is that we're already actively moving away from tasks to manage test clusters and this seems to use tasks to manage docker. The docker images are going to be much lighter than our test clusters so it is probably ok, but it does feel bad.

systemProperty 'es.set.netty.runtime.available.processors', 'false'
include '**/*IT.class'
include '**/*Tests.class'
doFirst {
fixtureProject.dockerCompose.servicesInfos.fixture.ports.forEach { container, host ->
logger.info(" adding system property fixture.smb-fixture.ports.$container -> $host")
Copy link
Member

Choose a reason for hiding this comment

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

Do you think we should move this to debug? It is nice to have but maybe not all the time.

@@ -46,13 +46,14 @@
// as we cannot control the URL of the referral which may contain a non-resolvable DNS name as
// this name would be served by the samba4 instance
public static final Boolean FOLLOW_REFERRALS = Booleans.parseBoolean(getFromEnv("TESTS_AD_FOLLOW_REFERRALS", "false"));
public static final String AD_LDAP_URL = getFromEnv("TESTS_AD_LDAP_URL", "ldaps://localhost:61636");
public static final String AD_LDAP_GC_URL = getFromEnv("TESTS_AD_LDAP_GC_URL", "ldaps://localhost:63269");
public static final String AD_LDAP_URL = getFromEnv("TESTS_AD_LDAP_URL", "ldaps://localhost:" + getFromProperty("636"));
Copy link
Member

Choose a reason for hiding this comment

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

Maybe name them rather than use the original port number? As much as I love port numbers I think it'd be nicer to call them LDAP and LDAP_GC or something.

environmentVars vagrantEnvVars
buildscript {
repositories {
jcenter()
Copy link
Member

Choose a reason for hiding this comment

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

I think jcenter is already in our build script.

dependsOn halt
task info() {
dependsOn composeUp
doLast { println dockerCompose.servicesInfos.fixture.ports }
Copy link
Member

Choose a reason for hiding this comment

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

Should this do compose down after?

@nik9000
Copy link
Member

nik9000 commented Nov 19, 2018

I'm thinking of pulling it into a plugin, to avoid repetition throughout the build.
Detecting docker-compose would be part of that and I think we can figure out from the plugin what needs to be disabled for the most part. I'll look at that next.

That makes sense to me!

I think before we merge this we should get that docker detection.

Copy link
Member

@rjernst rjernst 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 very happy with this as a better approach than vagrant, especially because it fixes the longstanding issue of hardcoded ports. Other than making sure this works in elasticsearch-ci, I just have one little nit.

systemProperty 'es.set.netty.runtime.available.processors', 'false'
include '**/*IT.class'
include '**/*Tests.class'
doFirst {
fixtureProject.dockerCompose.servicesInfos.fixture.ports.forEach { container, host ->
logger.info(" adding system property fixture.smb-fixture.ports.$container -> $host")
Copy link
Member

Choose a reason for hiding this comment

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

nit: can you use ${container} so it is clear where the substitution ends vs string value? Same below with the actual system property.

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

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

LGTM.

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 20, 2018

I muted the failing tests since CI already has docker-compose.

Added the composePull command to the packer cache script to cache the container images when the CI image is built.

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 21, 2018

@elasticmachine test this please

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 26, 2018

Note to self. When this is merged, should add an issue to add fixtures for some projects like: x-pack/qa/third-party/jira/build.gradle which require an external one so these can run in regular CI.

@alpar-t
Copy link
Contributor Author

alpar-t commented Nov 27, 2018

@rjernst do you want to take another look ? I made some changes after you approved.

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

LGTM, one nit

@@ -0,0 +1,12 @@
FROM ubuntu:16.04
RUN apt-get update -qqy && apt-get install -qqy samba ldap-utils
Copy link
Member

Choose a reason for hiding this comment

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

Now that installsmb.sh is being run in the docker file, I think installing samba and ldap-utils should move back into there?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't have a strong opinion on that, and don't mind doing it in a follow up.
One advantage of keeping these separate is that one can iterate on the install script without waiting for apt all the time, but having everything in the same script is also nice.

@alpar-t alpar-t merged commit 45db829 into elastic:master Nov 29, 2018
@alpar-t alpar-t deleted the replace-vagrant-fixtures-docker-compose branch November 29, 2018 07:43
alpar-t added a commit that referenced this pull request Nov 29, 2018
Creates a new plugin to manage docker-compose based test fixtures.
Convert the smb-fixture as a first example.
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >non-issue Team:Delivery Meta label for Delivery team v6.6.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants