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

Introduce packaging tests for Docker #46599

Merged
merged 18 commits into from
Oct 5, 2019

Conversation

pugnascotia
Copy link
Contributor

@pugnascotia pugnascotia commented Sep 11, 2019

Closes #37617. Add packaging tests for our Docker images, similar to what we have for RPMs or Debian packages. This works by running a container and probing it e.g. via docker exec. Test can also be run in Vagrant, by exporting the Docker images to disk and loading them again in VMs.

Notes:

  • Docker is installed via Vagrantfile in a selection of boxes. We could change the boxes built by Infra if we felt it was worthwhile, I wasn't sure.
  • The Docker images are only tested with the bundled JDK. It seemed counter to the spirit of using containers to run one using a bundled JDK, though there's nothing stopped a user doing that.

Add packaging tests for our Docker images, similar to what we have for
RPMs or Debian packages. This works by running a container and probing
it e.g. via `docker exec`. Test can also be run in Vagrant, by exporting
the Docker images to disk and loading them again in VMs. Docker is
installed via `Vagrantfile` in a selection of boxes.
@pugnascotia pugnascotia added >test Issues or PRs that are addressing/adding tests :Delivery/Build Build or test infrastructure :Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts v8.0.0 labels Sep 11, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Contributor

@dliappis dliappis left a comment

Choose a reason for hiding this comment

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

Great work this is really needed after integrating the Docker parts from the old separate repo!

I took an initial pass and left some comments.

Vagrantfile Outdated
@@ -183,6 +183,35 @@ def deb_common(config, name, extra: '')
install_command: 'apt-get install -y',
extra: extra_with_lintian
)
deb_docker(config)
Copy link
Contributor

Choose a reason for hiding this comment

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

As discussed privately, there's not much value running this on all distros (and not all support Docker like centos-6) so better be specific about where we call this.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be better to bake this into the image rather than install on-demand.
The CI packaging images already have docker ( at least the ones that support it ),
so we would need to add it to vagrant images only.

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'll sync with Infra about this, and remove it from Vagrantfile once the boxes include Docker.

Vagrantfile Outdated Show resolved Hide resolved
Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

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

Thanks for taking this on!
Unfortunately we don't have Pr checks for running these directly on jenkins workers, so it would be nice to test this before merging to make sure the CI jobs don't break.

Vagrantfile Outdated
@@ -183,6 +183,35 @@ def deb_common(config, name, extra: '')
install_command: 'apt-get install -y',
extra: extra_with_lintian
)
deb_docker(config)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be better to bake this into the image rather than install on-demand.
The CI packaging images already have docker ( at least the ones that support it ),
so we would need to add it to vagrant images only.

distribution/docker/build.gradle Outdated Show resolved Hide resolved
@@ -0,0 +1,2 @@
// This file is intentionally blank. All configuration of the
// export is done in the parent project.
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need a project for the extraction ? Could it just be a task on parent ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's to do with DistributionDownloadPlugin - as far as I can tell, it's written to create depdencies between ES distributions and the default config on a project. I'm new to Gradle, but it looks like it doesn't depend on a task because the plugin needs to be able to locate the built archives. I'd be very happy to be pointed at better ways of doing this. I had to spend a while deciphering what was going on between DistroTestPlugin and DistributionDownloadPlugin.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, the same pattern is used in :distribution:packages.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, it's a bit strange that this we have projects for export only here, but I'll defer to @rjernst

@pugnascotia
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

@pugnascotia
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging

@pugnascotia
Copy link
Contributor Author

Mysterious - for some reason, the centos-6 Vagrant box is not only trying to install Docker when it shouldn't be, it's trying to do with apt-get! 🤷‍♂

Copy link
Contributor

@dliappis dliappis left a comment

Choose a reason for hiding this comment

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

Left a few more contents related to the Vagrantfile.

Vagrantfile Outdated
@@ -185,6 +191,34 @@ def deb_common(config, name, extra: '')
)
end

def deb_docker(config)
config.vm.provision 'install Docker using apt', run: 'always', type: 'shell', inline: <<-SHELL
Copy link
Contributor

Choose a reason for hiding this comment

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

Is run: 'always' here on purpose? Do we intend to attempt to install docker on every vagrant up/reload operation? Details here.

Vagrantfile Outdated Show resolved Hide resolved
Vagrantfile Outdated Show resolved Hide resolved
Vagrantfile Outdated Show resolved Hide resolved
@pugnascotia
Copy link
Contributor Author

Thanks @dliappis - facepalms aplenty. 🤦‍♂

@pugnascotia
Copy link
Contributor Author

@elasticmachine update branch

@pugnascotia
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging

@pugnascotia
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging as there was a transient error.

@pugnascotia
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging as Jenkins restarted.

It turns out that it's not the same as Debian.
@pugnascotia
Copy link
Contributor Author

CI is green if someone would like to give me a LGTM?

Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

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

LGTM

We still have to make sure this works with the new workers.
If #46924 is merged, PR checks for it are coming soon, if this happens to be merged before, I'll re test to make sure before merging mine.

@pugnascotia
Copy link
Contributor Author

@atorok is your PR close to merging? I don't mind waiting if it is.

@pugnascotia pugnascotia closed this Oct 1, 2019
@pugnascotia pugnascotia reopened this Oct 1, 2019
@alpar-t
Copy link
Contributor

alpar-t commented Oct 1, 2019

@atorok is your PR close to merging? I don't mind waiting if it is.

Yes it is.

@pugnascotia
Copy link
Contributor Author

@elasticmachine update branch

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.

Thanks for the work here! Better testing of our docker images is greatly needed.

After reading through this, it appears we are running docker within each VM. At first I was confused by this, but I guess this matches up with docker being another distribution, and we want to test it on each platform (similar to how we test java on each platform).

One general thing I noticed though is we seem to have duplicated a lot of the assertions that exist within the archive tests. This would mean making any change to the archive structure would require changing multiple tests. Could we reuse these assertions?

@@ -370,7 +370,8 @@ private static void addDistro(NamedDomainObjectContainer<ElasticsearchDistributi
if (type == Type.ARCHIVE) {
d.setPlatform(platform);
}
d.setBundledJdk(bundledJdk);
// We don't test Docker images with a non-bundled JDK
d.setBundledJdk(type == Type.DOCKER || bundledJdk);
Copy link
Member

Choose a reason for hiding this comment

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

This should be handled outside of addDistro, otherwise we are adding the same distribution twice? ie around line 325 where this method is called

distro.getPlatform(),
distro.getFlavor(),
// We don't test Docker images with a non-bundled JDK
type == Type.DOCKER || distro.getBundledJdk());
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't be necessary, see my previous comment about where we add the distros. We should never add a docker distro with bundledJdk=false

if (subProject.name.contains('docker-export')) {
apply plugin: 'distribution'

def oss = subProject.name.startsWith('oss')
Copy link
Member

Choose a reason for hiding this comment

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

Please use static types. It makes the code easier to reason about, eg String here.

/**
* Check that a keystore can be manually created using the provided CLI tool.
*/
public void test40CreateKeystoreManually() throws InterruptedException {
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't really match with the pattern we've been working towards. We want test classes for categories of checks, like keystore related (which @williamrandolph has been splitting out in a separate PR). Which distribution is being used should not matter to the test, only that we know how to do primitive operations for the given distribution (eg start, stop, run cli tool, etc)

* Check whether the elasticsearch-certutil tool has been shipped correctly,
* and if present then it can execute.
*/
public void test90SecurityCliPackaging() {
Copy link
Member

Choose a reason for hiding this comment

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

We definitely don't want to have copies of every test in archive tests. Most of that class needs to be broken up. I wonder if in the interum ArchiveTests could be adapted to run when docker type is used?

@@ -57,12 +64,17 @@ public boolean isPackage() {
return packaging == Packaging.RPM || packaging == Packaging.DEB;
}

public boolean isDocker() {
Copy link
Member

Choose a reason for hiding this comment

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

Why is this needed? It doesn't seem any clearer than packaging == Packaging.DOCKER

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be honest I was copying the pattern of the existing code. e.g. isArchive() is only called in one place 🤷‍♂. I can remove it.

).forEach(dir -> assertPermissionsAndOwnership(dir, p755));

Stream.of(
"elasticsearch",
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should copy everything that is in Archives. This can (and will) get out of sync. I think we need to think more about how to decouple the checks so they can run agnostically.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about I do that in a follow-up PR? This one has been waiting to merge for a while. I can then take the time to refactor the packaging tests more generally.

@pugnascotia
Copy link
Contributor Author

I'm going to merge this PR as-is, and once #44775 is merged, I'll refactor the packaging tests to reduce duplication. The infrastructure here will unblock @dliappis and another PR of mine.

@pugnascotia pugnascotia merged commit da59dfe into elastic:master Oct 5, 2019
@pugnascotia pugnascotia deleted the docker-packaging-tests branch October 5, 2019 14:40
@alpar-t
Copy link
Contributor

alpar-t commented Oct 7, 2019

@alpar-t
Copy link
Contributor

alpar-t commented Oct 7, 2019

@pugnascotia sorry I missed this during review, we really want to back-port testing and build related changes like this, especially anything that changes the build code needs to be back-ported so the code doesn't diverge making it easy to port improvement to older branches that are still built in CI.

@pugnascotia
Copy link
Contributor Author

No problem, happy to backport.

Re: the CI failure, it looks like the docker build step failed, which I'm pretty sure is transient and not related to my changes. yum is complaining about its mirrors.

@alpar-t
Copy link
Contributor

alpar-t commented Oct 7, 2019

I added more details to #47639 there's more to it, and some of the tests fail too

pugnascotia added a commit to pugnascotia/elasticsearch that referenced this pull request Nov 5, 2019
Closes elastic#37617. Add packaging tests for our Docker images, similar to what
we have for RPMs or Debian packages. This works by running a container and
probing it e.g. via `docker exec`. Test can also be run in Vagrant, by
exporting the Docker images to disk and loading them again in VMs. Docker
is installed via `Vagrantfile` in a selection of boxes.
pugnascotia added a commit that referenced this pull request Nov 5, 2019
Backport of #46599 and #47640. Add packaging tests for Docker.

* Introduce packaging tests for Docker (#46599)

Closes #37617. Add packaging tests for our Docker images, similar to what
we have for RPMs or Debian packages. This works by running a container and
probing it e.g. via `docker exec`. Test can also be run in Vagrant, by
exporting the Docker images to disk and loading them again in VMs. Docker
is installed via `Vagrantfile` in a selection of boxes.

* Only define Docker pkg tests if Docker is available (#47640)

Closes #47639, and unmutes tests that were muted in b958467.

The Docker packaging tests were being defined irrespective of whether
Docker was actually available in the current environment. Instead,
implement exclude lists so that in environments where Docker is not
available, no Docker packaging tests are defined. For CI hosts, the build
checks `.ci/dockerOnLinuxExclusions`. The Vagrant VMs can defined the
extension property `shouldTestDocker` property to opt-in to packaging
tests.

As part of this, define a seperate utility class for checking Docker,
and call that instead of defining checks in-line in BuildPlugin.groovy
@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
backport pending :Delivery/Build Build or test infrastructure :Delivery/Packaging RPM and deb packaging, tar and zip archives, shell and batch scripts Team:Delivery Meta label for Delivery team >test Issues or PRs that are addressing/adding tests v7.5.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add docker packaging tests
7 participants