Skip to content
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
112 changes: 0 additions & 112 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
Expand Up @@ -1051,118 +1051,6 @@ updates:
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/centos-6/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/centos-7/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/debian-8/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/debian-9/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/fedora-28/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/fedora-29/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/oel-6/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/oel-7/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/sles-12/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/ubuntu-1604/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/ubuntu-1804/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/windows-2012r2/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/os/windows-2016/
open-pull-requests-limit: 1
package-ecosystem: gradle
schedule:
interval: weekly
labels:
- "dependabot"
- "dependencies"
- directory: /qa/remote-clusters/
open-pull-requests-limit: 1
package-ecosystem: gradle
Expand Down
99 changes: 0 additions & 99 deletions TESTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -290,105 +290,6 @@ For example :

You can launch a local OpenSearch cluster in debug mode following [Launching and debugging from an IDE](#launching-and-debugging-from-an-ide), and run your REST tests against that following [Running REST Tests Against An External Cluster](#running-rest-tests-against-an-external-cluster).

# Testing packaging

The packaging tests use Vagrant virtual machines or cloud instances to verify that installing and running OpenSearch distributions works correctly on supported operating systems. These tests should really only be run on ephemeral systems because they’re destructive; that is, these tests install and remove packages and freely modify system settings, so you will probably regret it if you execute them on your development machine.

When you run a packaging test, Gradle will set up the target VM and mount your repository directory in the VM. Once this is done, a Gradle task will issue a Vagrant command to run a **nested** Gradle task on the VM. This nested Gradle runs the actual "destructive" test classes.

1. Install Virtual Box and Vagrant.

2. (Optional) Install [vagrant-cachier](https://github.com/fgrehm/vagrant-cachier) to squeeze a bit more performance out of the process (Note: as of 2021, vagrant-cachier is unmaintained):

vagrant plugin install vagrant-cachier

3. You can run all the OS packaging tests with `./gradlew packagingTest`. This task includes our legacy `bats` tests.

To run only the OS tests that are written in Java, run `.gradlew distroTest`, will cause Gradle to build the tar, zip, and deb packages and all the plugins. It will then run the tests on every available system. This will take a very long time.

Fortunately, the various systems under test have their own Gradle tasks under `qa/os`. To find out what packaging combinations can be tested on a system, run the `tasks` task. For example:

./gradlew :qa:os:ubuntu-1804:tasks

If you want a quick test of the tarball and RPM packaging for Centos 7, you would run:

./gradlew :qa:os:centos-7:distroTest.rpm :qa:os:centos-7:distroTest.linux-archive

Note that if you interrupt Gradle in the middle of running these tasks, any boxes started will remain running, and you’ll have to stop them manually with `./gradlew --stop` or `vagrant halt`.

All the regular vagrant commands should just work, so you can get a shell in a VM running trusty by running `vagrant up ubuntu-1604 --provider virtualbox && vagrant ssh ubuntu-1604`.

These are the linux flavors supported, all of which we provide images for

- ubuntu-1604 aka xenial
- ubuntu-1804 aka bionic beaver
- debian-8 aka jessie
- debian-9 aka stretch, the current debian stable distribution
- centos-6
- centos-7
- rhel-8
- fedora-28
- fedora-29
- oel-6 aka Oracle Enterprise Linux 6
- oel-7 aka Oracle Enterprise Linux 7
- sles-12
- opensuse-42 aka Leap

We’re missing the following from the support matrix because there are no high quality boxes available in vagrant atlas:

- sles-11

## Testing packaging on Windows

The packaging tests also support Windows Server 2012R2 and Windows Server 2016. Unfortunately we’re not able to provide boxes for them in open source use because of licensing issues. Any Virtualbox image that has WinRM and Powershell enabled for remote users should work.

Testing on Windows requires the [vagrant-winrm](https://github.com/criteo/vagrant-winrm) plugin.

vagrant plugin install vagrant-winrm

Specify the image IDs of the Windows boxes to gradle with the following project properties. They can be set in `~/.gradle/gradle.properties` such as

vagrant.windows-2012r2.id=my-image-id
vagrant.windows-2016.id=another-image-id

or passed on the command line such as `-Pvagrant.windows-2012r2.id=my-image-id` or `-Pvagrant.windows-2016=another-image-id`

These properties are required for Windows support in all gradle tasks that handle packaging tests. Either or both may be specified.

If you’re running vagrant commands outside of gradle, specify the Windows boxes with the environment variables.

- `VAGRANT_WINDOWS_2012R2_BOX`
- `VAGRANT_WINDOWS_2016_BOX`

## Testing VMs are disposable

It’s important to think of VMs like cattle. If they become lame you just shoot them and let vagrant reprovision them. Say you’ve hosed your precise VM:

vagrant ssh ubuntu-1604 -c 'sudo rm -rf /bin'; echo oops

All you’ve got to do to get another one is

vagrant destroy -f ubuntu-1604 && vagrant up ubuntu-1604 --provider virtualbox

The whole process takes a minute and a half on a modern laptop, two and a half without vagrant-cachier.

Some vagrant commands will work on all VMs at once:

vagrant halt
vagrant destroy -f

`vagrant up` would normally start all the VMs, but we’ve prevented that because that’d consume a ton of ram.

## Iterating on packaging tests

Because our packaging tests are capable of testing many combinations of OS (e.g., Windows, Linux, etc.), package type (e.g., zip file, RPM, etc.) and so forth, it’s faster to develop against smaller subsets of the tests. For example, to run tests for the default archive distribution on Fedora 28:

./gradlew :qa:os:fedora-28:distroTest.linux-archive

These test tasks can use the `--tests`, `--info`, and `--debug` parameters just like non-OS tests can. For example:

./gradlew :qa:os:fedora-28:distroTest.linux-archive --tests "com.opensearch.packaging.test.ArchiveTests"

# Testing backwards compatibility

Backwards compatibility tests exist to test upgrading from each supported version to the current version.
Expand Down
Loading
Loading