Skip to content

Initial support for extended integration test - #1230

Merged
openshift-bot merged 2 commits into
openshift:masterfrom
mfojtik:ext_int_test_poc
Mar 19, 2015
Merged

Initial support for extended integration test#1230
openshift-bot merged 2 commits into
openshift:masterfrom
mfojtik:ext_int_test_poc

Conversation

@mfojtik

Copy link
Copy Markdown
Contributor

This is highly WIP atm. I have this here just to gather feedback and thoughts ;-)

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@bparees@csrwng@soltysh PTAL

To execute extended tests, you have to:

OS_TEST_TAGS="integration extended docker" ./hack/test-integration.sh -v=5

I don't like that I need to start the OpenShift server (all-in-one), since that breaks the parallelization of tests (I dunno if it is good idea to have multiple OpenShift server/etcd/... running simultaneously)...

The second thing I don't like is that I can't verify the application is working without having Docker registry in place... Right now, the build does not have any Output defined and I just assume that when it finishes as 'Complete' there was no error during the STI build....
I would love to have access to 'logs' (docker logs/buildLogs) at some point to verify that the 'contextDir' applied here (the files were copied from subdir).
Without this capability, I can't test properly things like '.sti/environment', because I don't have access to the output image...

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

FYI. this should be probably solved by using Watch() instead of polling, I just need to get familiar with the Watch() itself first...

@csrwng

Copy link
Copy Markdown
Contributor

I don't like that I need to start the OpenShift server (all-in-one), since that breaks the parallelization of tests (I dunno if it is good idea to have multiple OpenShift server/etcd/... running simultaneously)...

Could we start the all-in-one server, set it up, then run all tests in parallel (each using its own namespace)?

The second thing I don't like is that I can't verify the application is working without having Docker registry in place...

I was under the impression that what we wanted was a go version of the e2e tests with everything setup, including the registry. (so e2e extended posing as an integration test)

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@csrwng if extended tests will be a new set of tests, then I don't think I can re-use the code in integration... (dunno if I can just import the test_server.go ;-)

@csrwng

Copy link
Copy Markdown
Contributor

That's what I thought we were going to do :-)

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@csrwng I can still move this into its own package :-) (this is the feedback I was hoping for :-)

@csrwng

Copy link
Copy Markdown
Contributor

@csrwng I can still move this into its own package :-) (this is the feedback I was hoping for :-)

You have my vote

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@csrwng so the command to launch the tests is now:

OS_TEST_PACKAGE="test/extended" OS_TEST_TAGS="integration extended docker" ./hack/test-integration.sh

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Instead of having those bits and pieces here and there, let's create a test/util package and put there all the utility stuff such as RequireDocker, RequireEtcd, etc.

@csrwng

Copy link
Copy Markdown
Contributor

@csrwng so the command to launch the tests is now:

we should add a hack/test-extended.sh to run it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think we are overusing those, especially in that we do copy&paste for other integration tests. I think it would make sense to clear this out doing this. Since for this test you are requiring etcd and docker this line should state:

// +build integration,extended,etcd,docker

IMHO

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

there should be no tags at all here...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think you may want to leave integration,extended since you're passing those with OS_TEST_TAGS

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should it just be extended? these tests aren't run when hack/test-integration.sh is run (because they're in a different package), so tagging them as integration is a bit confusing.

@soltysh

Copy link
Copy Markdown
Contributor

🌻 for the idea itself

@soltysh

Copy link
Copy Markdown
Contributor

we should add a hack/test-extended.sh to run it

+1

Maybe call it hack/test-integration-extended.sh to follow integration tests pattern.

@bparees

Copy link
Copy Markdown
Contributor

I think it's reasonable to start the registry service as part of the basic integration test environment setup.

and i agree w/ @csrwng that we should be able to run in parallel by using appropriate namespaces (though that probably means we need some more generic framework that will dynamically generate unique namespaces and substitute it into templates/etc, otherwise we're relying on everyone to create their tests using unique namespaces).

also currently namespaces don't work for services...upstream issue still pending.

@bparees

Copy link
Copy Markdown
Contributor

might be useful to have a soft-reset for openshift... ie "delete all pods/etc, clean up etcd (maybe just cleaning up etcd is sufficient), stop all docker containers"

might be faster than starting openshift again for each test.

though given that you'd need to purge/restart the registry too i guess it probably wouldn't save much time.....i just worry about how long each integration test is going to take if we have to start openshift and wait for the registry to deploy....that's like 60s just in startup time per test. I know part of the point of this is to have a place for longer tests to live, but still.

@soltysh

Copy link
Copy Markdown
Contributor

I guess then it'll be simpler and faster at the same time, to generate new namespace for each test. Eg. we could be generating env var called TEST_NAMESPACE and all tests would be then consuming that.

@mfojtik
mfojtikforce-pushed the ext_int_test_poc branch 2 times, most recently from c30caa4 to 19159d0CompareMarch 6, 2015 12:00
Comment threadhack/test-integration.sh Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can't we have that verbosity connected with VERBOSE env var?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why would you need the build to be verbose?

@mfojtik
mfojtikforce-pushed the ext_int_test_poc branch 2 times, most recently from d661722 to da2b5b3CompareMarch 16, 2015 11:53
@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@bparees@csrwng

I updated this:

  • OpenShift server is now started by test-extended.sh
  • GetClient() method was added into server.go so you can obtain an osclient you use in your tests
  • More smaller refactorings and tweaks to have these tests running consistently

PTAL

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

FYI, now you execute the tests using:

./hack/test-extended.sh

(you can optionally set VERBOSE=1 before you run that command to get more verbose output...)

@mfojtikmfojtik changed the title WIP [DO_NOT_MERGE]: Extended integration testInitial support for extended integration testMar 16, 2015
Comment threadhack/test-extended.sh Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Using ${TMPDIR:-/tmp} instead of /tmp would be useful in case you want to use a different temp directory

@openshift-bot

Copy link
Copy Markdown
Contributor

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1375/)

@mfojtik
mfojtikforce-pushed the ext_int_test_poc branch 3 times, most recently from 25c4464 to 443700eCompareMarch 19, 2015 09:48
@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@deads2k can you please check the latest failure? I think it has something to do with Policies vs Namespaces but I can't figure out what broke there....

@mfojtik
mfojtikforce-pushed the ext_int_test_poc branch 5 times, most recently from 3e1bf88 to 153b70dCompareMarch 19, 2015 11:01
@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@deads2k this might be related:

I0319 11:01:44.033426 7246 master.go:442] No master policy found. Creating bootstrap policy based on: /tmp/openshift-integration/policy/policy.json
E0319 11:01:44.265429 7246 master.go:445] Error creating bootstrap policy: policyBinding "openshift" not found

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

Also I wonder why TestDNS requires Docker:

W0319 11:32:07.796088 7921 node.go:96] Error running 'chcon' to set the kubelet volume root directory SELinux context: exit status 1
F0319 11:32:07.796252 7921 node.go:61] ERROR: Docker could not be reached at unix:///var/run/docker.sock. Docker must be installed and running to start containers.

@deads2kdeads2k mentioned this pull request Mar 19, 2015
@mfojtik
mfojtikforce-pushed the ext_int_test_poc branch 3 times, most recently from 50e8fd0 to 864bedbCompareMarch 19, 2015 13:14
@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@csrwng@bparees@soltysh PTAL

I would really like to have this merged ASAP as this is getting broken everyday (as somebody push something into integration tests). I can fix small issues as follow up.

@csrwng

Copy link
Copy Markdown
Contributor

LGTM but it looks like integration tests are still failing on go 1.4

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

@csrwng yeah, I saw this failure on other PR as well and @deads2k is looking into it... It does not seem that my changes made it worse/better.

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

[merge]

(will fix all issues as follow up)

@openshift-bot

Copy link
Copy Markdown
Contributor

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1223/) (Image: devenv-fedora_1081)

@mfojtik

Copy link
Copy Markdown
ContributorAuthor

[merge] again.. seems like random failure

@openshift-bot

Copy link
Copy Markdown
Contributor

Evaluated for origin up to 47caf77

openshift-bot pushed a commit that referenced this pull request Mar 19, 2015
@openshift-bot
openshift-bot merged commit 814026a into openshift:masterMar 19, 2015
@mfojtik
mfojtik deleted the ext_int_test_poc branch September 5, 2018 21:07
Sign up for freeto 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.

6 participants

@mfojtik@csrwng@soltysh@bparees@openshift-bot@smarterclayton