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

add preflight checks integration tests #3816

Merged
merged 5 commits into from
Apr 26, 2017
Merged

add preflight checks integration tests #3816

merged 5 commits into from
Apr 26, 2017

Conversation

sosiouxme
Copy link
Member

@sosiouxme sosiouxme commented Mar 30, 2017

Adds some integration tests that can run preflight checks against inventory made up of throwaway docker containers, and test for expected results.

@sosiouxme
Copy link
Member Author

sosiouxme commented Mar 31, 2017

@rhcarvalho The golang part of this is really just running playbooks (in parallel), checking for expected outcomes, and displaying the results nicely. It does seem like the sort of thing that could be done with pytest instead, and prettier.

Re boilerplate, I think I've reduced the setup part about as much as possible. It is probably worth exploring a callback plugin for teardown rather than having the exception-handling block in every test.

I don't know that we need to block this PR in order to finish that work though. Just a couple small things I'd like to do first:

  • rip out the example tests
  • get TestPackageAvailabilitySucceeds fixed or skipped

@rhcarvalho
Copy link
Contributor

The golang part of this is really just running playbooks (in parallel), checking for expected outcomes, and displaying the results nicely. It does seem like the sort of thing that could be done with pytest instead, and prettier.

The experiment to be done is to use pytest + pytest-xdist. And look out for flakiness.

@sosiouxme sosiouxme changed the title [WIP] add preflight checks integration tests add preflight checks integration tests Mar 31, 2017
@sosiouxme
Copy link
Member Author

So, yeah... did those little things.

@sosiouxme
Copy link
Member Author

sosiouxme commented Apr 3, 2017

The tests all pass if I run go test ./test/integration/...

However with tox -e integration all fail immediately with

                 Task:     openshift_sanitize_inventory : Ensure a valid deployment type has been given.
                 Message:  Please set openshift_deployment_type to one of:
                           origin, online, enterprise, atomic-enterprise, openshift-enterprise

I don't understand what the difference is between the two.

@sosiouxme
Copy link
Member Author

sosiouxme commented Apr 3, 2017

Digging a little deeper, tox seems to be running its own ansible, which doesn't work quite the same as the system ansible I get from my path when I run ansible-playbook more directly. I get the same result if I run the vendored ansible. I bumped up debugging and had a closer look. The setup step runs a little differently, and afterward the facts seem to be wiped out. Not sure what's happening here:

                TASK [setup] *******************************************************************
                Using module file /root/openshift-ansible/.tox/integration/lib/python2.7/site-packages/ansible/modules/core/system/setup.py
                <openshift_ansible_test_84089141491733> ESTABLISH DOCKER CONNECTION FOR USER: root
                <openshift_ansible_test_84089141491733> EXEC ['/bin/docker', 'exec', '-i', u'openshift_ansible_test_84089141491733', u'/bin/sh', '-c', u"/bin/sh -c 'echo ~ && sleep 0'"]
                <openshift_ansible_test_84089141491733> EXEC ['/bin/docker', 'exec', '-i', u'openshift_ansible_test_84089141491733', u'/bin/sh', '-c', u'/bin/sh -c \'( umask 77 && mkdir -p "` echo /root/.ansible
/tmp/ansible-tmp-1491254488.22-118473355611698 `" && echo ansible-tmp-1491254488.22-118473355611698="` echo /root/.ansible/tmp/ansible-tmp-1491254488.22-118473355611698 `" ) && sleep 0\'']
                <openshift_ansible_test_84089141491733> PUT /tmp/tmpGaXB9Q TO /root/.ansible/tmp/ansible-tmp-1491254488.22-118473355611698/setup.py
                <openshift_ansible_test_84089141491733> EXEC ['/bin/docker', 'exec', '-i', u'openshift_ansible_test_84089141491733', u'/bin/sh', '-c', u"/bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-14912
54488.22-118473355611698/ /root/.ansible/tmp/ansible-tmp-1491254488.22-118473355611698/setup.py && sleep 0'"]
                <openshift_ansible_test_84089141491733> EXEC ['/bin/docker', 'exec', '-i', u'openshift_ansible_test_84089141491733', u'/bin/sh', '-c', u'/bin/sh -c \'/usr/bin/python /root/.ansible/tmp/ansible-tm
p-1491254488.22-118473355611698/setup.py; rm -rf "/root/.ansible/tmp/ansible-tmp-1491254488.22-118473355611698/" > /dev/null 2>&1 && sleep 0\'']
                ok: [openshift_ansible_test_84089141491733]
                
                TASK [openshift_sanitize_inventory : Standardize on latest variable names] *****
                task path: /root/openshift-ansible/roles/openshift_sanitize_inventory/tasks/main.yml:2
                ok: [openshift_ansible_test_84089141491733] => {
                    "ansible_facts": {
                        "deployment_type": "", 
                        "openshift_deployment_type": ""
                    }, 
                    "changed": false, 
                    "invocation": {
                        "module_args": {
                            "deployment_type": "", 
                            "openshift_deployment_type": ""
                        }, 
                        "module_name": "set_fact"
                    }
                }

@sosiouxme
Copy link
Member Author

Tests run if I modify requirements.txt to have ansible==2.2.1.0 instead of ansible>=2.2 - argh! Ansible regression apparently...

requirements.txt Outdated
@@ -1,4 +1,6 @@
ansible>=2.2
# ansible 2.2.2.0 inexplicably fails integration tests under tox;
Copy link
Member Author

Choose a reason for hiding this comment

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

I did get tests to run fine from a source checkout of ansible-2.2.2.0 but tox uses what pip gets so it seems there is still some difference.

Copy link
Contributor

Choose a reason for hiding this comment

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

What's the error you saw?

Copy link
Member Author

Choose a reason for hiding this comment

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

described at #3816 (comment)

I really don't want this in here so I'll keep fiddling with it as the CI work comes along.

@sosiouxme
Copy link
Member Author

@sdodson this adds integration tests to tox. However they're not running in travis and I assume they should be. How do we make that happen? How do we get them running in the jenkins test/merge also/instead?

Also how do we ensure the local requirements of the tests (docker + golang) are available?

@rhcarvalho
Copy link
Contributor

However they're not running in travis and I assume they should be. How do we make that happen? How do we get them running in the jenkins test/merge also/instead?

Hey, we will probably not run them on Travis. Our usage of Travis within the openshift/* organization repos should be and stay light, as we have only (IIRC) 2 concurrent builds for all repos.

As integration tests start taking time to run, we don't want to be affecting Travis builds across all projects.

@sosiouxme
Copy link
Member Author

sosiouxme commented Apr 5, 2017

Right, makes sense. So I'm curious why travis isn't trying to run integration tests now? It's just another environment in tox.ini added in this PR.

@rhcarvalho
Copy link
Contributor

Right, makes sense. So I'm curious why travis isn't trying to run integration tests now? It's just another environment in tox.ini added in this PR.

Can't see to find it... I have a vague memory that tox only run environments matching the list of defaults:
http://tox.readthedocs.io/en/latest/example/basic.html#a-simple-tox-ini-default-environments

So to run an environment "foo" you have to explicitly select it: tox -e foo; tox -e integration.

requirements.txt Outdated
@@ -1,4 +1,6 @@
ansible>=2.2
# ansible 2.2.2.0 inexplicably fails integration tests under tox;
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the error you saw?

or increase concurrency:

```
go test ./test/integration/... -p 8 -run TestPackageUpdateDepMissing
Copy link
Contributor

Choose a reason for hiding this comment

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

-p tells go test how many packages to test in parallel... -parallel operates within a single package.

Either way, I'd leave this discussion off the README and go with the defaults (based on number of CPU cores).

Copy link
Member Author

Choose a reason for hiding this comment

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

did not know that, interesting. Actually the test script will provide this option, so I'll just leave it out of the README.

@@ -0,0 +1,2 @@
FROM centos/systemd
RUN yum install -y iproute python-dbus PyYAML yum-utils
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 I never understood why openshift-ansible doesn't use ansible to install those... @sosiouxme do you happen to know?

checks: [ 'package_update' ]

always: # destroy the container whether check passed or not
- include: ../../teardown_container.yml
Copy link
Contributor

Choose a reason for hiding this comment

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

We need to isolate setup and teardown from the actual test, to avoid copy-pasting this snippet all the time.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed about teardown, I'm pretty sure that can go in a callback plugin.

For setup, you're always going to need some way to specify the various parameters for the host, which is most of what's copy-pasted. It could be a little cleaner if there were a setup action or something like that.

Copy link
Contributor

Choose a reason for hiding this comment

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

We might have better luck using the test framework for that, not YAML.

import (
"testing"

. ".."
Copy link
Contributor

Choose a reason for hiding this comment

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

FTR, this is something I wrote and I don't like it; but to use absolute imports we need to have the code checked out appropriately within a GOPATH.

@sosiouxme sosiouxme changed the title add preflight checks integration tests [WIP] add preflight checks integration tests Apr 12, 2017
@rhcarvalho
Copy link
Contributor

rhcarvalho commented Apr 13, 2017

The unit test failures (incl. Travis) were caused by the way we instantiate action plugins in tests, something that manifested itself only in Ansible 2.3 and fixed in #3919.

@sosiouxme
Copy link
Member Author

docker-py is needed on the host. thinking of running this under tox after all...

@sosiouxme
Copy link
Member Author

So now the integration tests actually run, and fail the same way they do locally for me. So it's not just something nuts about my setup. Progress!

@sosiouxme
Copy link
Member Author

sosiouxme commented Apr 17, 2017

The test runner fails under ansible 2.2.2+ because it no longer sets facts on the test hosts the way it's supposed to. I do not think we want to drag the rest of the tests back to ansible 2.2.1 so I created a separate tox config under test/integration until this bug is fixed. It's not ideal but it keeps this PR moving.

@sosiouxme sosiouxme changed the title [WIP] add preflight checks integration tests add preflight checks integration tests Apr 17, 2017
@sosiouxme
Copy link
Member Author

STARTTIME=$(date +%s)
source_root=$(dirname "${0}")

prefix="${PREFIX:-openshift-ansible-integration-}"
Copy link
Contributor

Choose a reason for hiding this comment

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

I noticed we're defaulting this value in multiple places -- 5 occurrences of openshift-ansible-integration- in this PR. What's the case when we would actually use a different prefix?!

Copy link
Member Author

@sosiouxme sosiouxme Apr 18, 2017

Choose a reason for hiding this comment

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

That case is when we're building the images separately and pushing them to a shared registry to be used in tests running in later CI jobs. I wrote this originally expecting that's what we would do, then I learned the shared registry isn't ready yet. Assuming that becomes available, it should just require setting parameters in the Jenkins jobs.

go test ./${source_root#$PWD}/... ${gotest_options} \
|| retval=$?

ENDTIME=$(date +%s); echo "$0 took $(($ENDTIME - $STARTTIME)) seconds"
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 this is a copy-paste from scripts in Origin... go test already prints how long tests took, we could simplify the script and its output by removing this. WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

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

Would be fine with me; FWIW this also captures the time to set up the virtualenv. shrug

Copy link
Member Author

Choose a reason for hiding this comment

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

ripped out

@@ -0,0 +1,14 @@
[tox]
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 we had a different requirement on the Ansible version because of the issue with delegate_to, but we could probably still get away with a single tox.ini file in the repository. Earlier this year we've unified /tox.ini and /utils/tox.ini to avoid having to maintain two sets of configuration 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.

Would be happy to do that. I'm not an expert on tox config :) but it looked to me like that would mean specifying ansible version individually in tox.ini on each environment. Otherwise, if I left the ansible requirement in shared requirements.txt and tried to specify a different one just for integration, it complained about the mismatch. Is there a way to do it?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's good to keep ansible in requirements.txt, because for a python developer that's the fist place she would look into and setup runtime requirements in a virtual env (unrelated to tox).

The mismatch is most likely related to how pip works so far... I remember seeing an open issue to allow it to resolve required versions when two sources ask for different versions. The workaround is to call pip twice.

Copy link
Member Author

Choose a reason for hiding this comment

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

How do you get tox to call pip twice with different reqs? Or I suppose we could call it manually to update ansible after tox, though that seems odd to me...

Copy link
Member Author

Choose a reason for hiding this comment

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

Have pip install ansible==2.2.1.0 be the integration test "command" :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, that's the workaround. I think we've done that before. Odd, yes :)

Copy link
Member Author

Choose a reason for hiding this comment

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

@rhcarvalho OK, done! Testing at https://ci.openshift.redhat.com/jenkins/job/test_pull_request_openshift_ansible_tox/61/ but local tests went fine so I expect it to work. Travis already passed.

@rhcarvalho
Copy link
Contributor

Tests ran fine at https://ci.openshift.redhat.com/jenkins/job/test_pull_request_openshift_ansible_tox/60/console

@sosiouxme do you know if there's any flag to make the output less verbose?

The interesting line is buried in a ton of useless minutia:

ok  	_/data/src/github.com/openshift/openshift-ansible/test/integration/openshift_health_checker/preflight	140.469s

More interesting than a GREEN test is to see how RED tests look like, and to make sure that when tests fail people can actually understand the output.

@sosiouxme
Copy link
Member Author

sosiouxme commented Apr 18, 2017 via email

@sosiouxme
Copy link
Member Author

aos-ci-test

@openshift-bot
Copy link

error: aos-ci-jenkins/OS_3.5_containerized for 1b94f60 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.5_NOT_containerized, aos-ci-jenkins/OS_3.5_NOT_containerized_e2e_tests" for 1b94f60 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.6_NOT_containerized, aos-ci-jenkins/OS_3.6_NOT_containerized_e2e_tests" for 1b94f60 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.5_NOT_containerized, aos-ci-jenkins/OS_3.5_NOT_containerized_e2e_tests" for bee527d (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.6_NOT_containerized, aos-ci-jenkins/OS_3.6_NOT_containerized_e2e_tests" for bee527d (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.5_containerized, aos-ci-jenkins/OS_3.5_containerized_e2e_tests" for bee527d (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.6_containerized, aos-ci-jenkins/OS_3.6_containerized_e2e_tests" for bee527d (logs)

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 20, 2017
@rhcarvalho
Copy link
Contributor

@sosiouxme this needs a rebase.

I haven't had time to try out using pytest-xdist as a test runner. Instead of blocking on this for longer, I'm okay with getting what we have in and following up later.

Please let's do our best to make sure our integration tests don't end up blocking the merge queue.

@rhcarvalho
Copy link
Contributor

also, there seems to be room for a git rebase -i to combine fixup commits.

rhcarvalho and others added 5 commits April 25, 2017 12:13
To make room for integration tests.
Make the container setup and teardown more reusable.
Remove example tests.
Add basic package tests.
Add some scripts that can be run from Jenkins to build/push test images
and to run the tests.
Updated README to expand on running tests.
@sosiouxme
Copy link
Member Author

@rhcarvalho I rebased, and rearranged commits a bit. I think the ones left are the right level of granularity. Will make sure the tests pass, need an approved review to merge...

# So for now, install separate ansible version for integration.
# PR that fixes it: https://github.com/ansible/ansible/pull/23599
# Once that PR is available, drop this and use same ansible.
integration: pip install ansible==2.2.1.0
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@@ -12,6 +13,7 @@ deps =
-rrequirements.txt
-rtest-requirements.txt
py35-flake8: flake8-bugbear==17.3.0
integration: docker-py==1.10.6
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@sosiouxme
Copy link
Member Author

aos-ci-test

@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 25, 2017
@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.5_NOT_containerized, aos-ci-jenkins/OS_3.5_NOT_containerized_e2e_tests" for e5f14b5 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.6_NOT_containerized, aos-ci-jenkins/OS_3.6_NOT_containerized_e2e_tests" for e5f14b5 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.6_containerized, aos-ci-jenkins/OS_3.6_containerized_e2e_tests" for e5f14b5 (logs)

@openshift-bot
Copy link

success: "aos-ci-jenkins/OS_3.5_containerized, aos-ci-jenkins/OS_3.5_containerized_e2e_tests" for e5f14b5 (logs)

@sosiouxme
Copy link
Member Author

[merge] at last

@openshift-bot
Copy link

[test]ing while waiting on the merge queue

@openshift-bot
Copy link

Evaluated for openshift ansible test up to e5f14b5

@openshift-bot
Copy link

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_openshift_ansible/75/) (Base Commit: d5ec349)

@sosiouxme
Copy link
Member Author

Flake openshift/origin#8571
re[merge]

@openshift-bot
Copy link

Evaluated for openshift ansible merge up to e5f14b5

@openshift-bot
Copy link

openshift-bot commented Apr 26, 2017

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_openshift_ansible/293/) (Base Commit: 760bdbc)

@openshift-bot openshift-bot merged commit c12b009 into openshift:master Apr 26, 2017
@sosiouxme sosiouxme deleted the 20170328-integration-tests branch May 3, 2017 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants