Uh oh!
There was an error while loading. Please reload this page.
Initial support for extended integration test - #1230
Conversation
mfojtik
commented
Mar 5, 2015
To execute extended tests, you have to: 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.... |
There was a problem hiding this comment.
FYI. this should be probably solved by using Watch() instead of polling, I just need to get familiar with the Watch() itself first...
csrwng
commented
Mar 5, 2015
Could we start the all-in-one server, set it up, then run all tests in parallel (each using its own namespace)?
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
commented
Mar 5, 2015
@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
commented
Mar 5, 2015
That's what I thought we were going to do :-) |
mfojtik
commented
Mar 5, 2015
@csrwng I can still move this into its own package :-) (this is the feedback I was hoping for :-) |
csrwng
commented
Mar 5, 2015
You have my vote |
mfojtik
commented
Mar 5, 2015
@csrwng so the command to launch the tests is now: |
There was a problem hiding this comment.
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
commented
Mar 5, 2015
we should add a hack/test-extended.sh to run it |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
there should be no tags at all here...
There was a problem hiding this comment.
I think you may want to leave integration,extended since you're passing those with OS_TEST_TAGS
There was a problem hiding this comment.
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
commented
Mar 5, 2015
🌻 for the idea itself |
soltysh
commented
Mar 5, 2015
+1 Maybe call it |
bparees
commented
Mar 5, 2015
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
commented
Mar 5, 2015
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
commented
Mar 5, 2015
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 |
c30caa4 to
19159d0CompareThere was a problem hiding this comment.
Can't we have that verbosity connected with VERBOSE env var?
There was a problem hiding this comment.
Why would you need the build to be verbose?
d661722 to
da2b5b3Comparemfojtik
commented
Mar 16, 2015
mfojtik
commented
Mar 16, 2015
FYI, now you execute the tests using: (you can optionally set VERBOSE=1 before you run that command to get more verbose output...) |
There was a problem hiding this comment.
Using ${TMPDIR:-/tmp} instead of /tmp would be useful in case you want to use a different temp directory
openshift-bot
commented
Mar 18, 2015
continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1375/) |
25c4464 to
443700eComparemfojtik
commented
Mar 19, 2015
@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.... |
3e1bf88 to
153b70dComparemfojtik
commented
Mar 19, 2015
@deads2k this might be related: |
mfojtik
commented
Mar 19, 2015
Also I wonder why TestDNS requires Docker: |
50e8fd0 to
864bedbComparemfojtik
commented
Mar 19, 2015
csrwng
commented
Mar 19, 2015
LGTM but it looks like integration tests are still failing on go 1.4 |
mfojtik
commented
Mar 19, 2015
mfojtik
commented
Mar 19, 2015
[merge] (will fix all issues as follow up) |
openshift-bot
commented
Mar 19, 2015
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1223/) (Image: devenv-fedora_1081) |
mfojtik
commented
Mar 19, 2015
[merge] again.. seems like random failure |
openshift-bot
commented
Mar 19, 2015
Evaluated for origin up to 47caf77 |
This is highly WIP atm. I have this here just to gather feedback and thoughts ;-)