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

[Arquillian Cube OpenShift] namespace.use.existing + env.init.enabled=true fails to create test resources #743

Closed
RadekKoubsky opened this Issue Jun 26, 2017 · 81 comments

Comments

Projects
None yet
5 participants
@RadekKoubsky

RadekKoubsky commented Jun 26, 2017

Issue Overview

I have my existing openshift project which si empty. I want arquillian cube to deploy test resources (e.g. openshift.yml) generated by FMP during resource goal. When running integration tests, arquillian cube throws the following exception about non-existing image stream:

Running io.openshift.booster.OpenShiftIT
Initializing Session:b13b197f-9d14-49f0-a628-571ccd39cef7
Using Kubernetes at: https://api.devel.xpaas:8443/
Did not find any kubernetes configuration.
Applying additional kubernetes configuration from: file:/home/rkoubsky/QE/MSA/forks/rkoubsky/rest_springboot-tomcat/target/spring-boot-http-is.yml
Could not annotate namespace: [rkoubsky] with status: [ERROR].
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.949 sec <<< FAILURE! - in io.openshift.booster.OpenShiftIT
io.openshift.booster.OpenShiftIT  Time elapsed: 3.948 sec  <<< ERROR!
java.lang.RuntimeException: io.fabric8.kubernetes.clnt.v2_2.KubernetesClientException: Failure executing: POST at: https://api.devel.xpaas:8443/oapi/v1/namespaces/rkoubsky/imagestreams. Message: ImageStream "spring-boot-http" is invalid: []: Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found. Received status: Status(apiVersion=v1, code=422, details=StatusDetails(causes=[StatusCause(field=[], message=Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found, reason=InternalError, additionalProperties={})], group=null, kind=ImageStream, name=spring-boot-http, retryAfterSeconds=null, additionalProperties={}), kind=Status, message=ImageStream "spring-boot-http" is invalid: []: Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found, metadata=ListMeta(resourceVersion=null, selfLink=null, additionalProperties={}), reason=Invalid, status=Failure, additionalProperties={}).
Caused by: io.fabric8.kubernetes.clnt.v2_2.KubernetesClientException: Failure executing: POST at: https://api.devel.xpaas:8443/oapi/v1/namespaces/rkoubsky/imagestreams. Message: ImageStream "spring-boot-http" is invalid: []: Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found. Received status: Status(apiVersion=v1, code=422, details=StatusDetails(causes=[StatusCause(field=[], message=Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found, reason=InternalError, additionalProperties={})], group=null, kind=ImageStream, name=spring-boot-http, retryAfterSeconds=null, additionalProperties={}), kind=Status, message=ImageStream "spring-boot-http" is invalid: []: Internal error: imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d": error generating tag event: imagestreamimage "sha256:ae65653b28535fac376fc62f9b4fda24206152964ca1b6884c621cc2e633698d" not found, metadata=ListMeta(resourceVersion=null, selfLink=null, additionalProperties={}), reason=Invalid, status=Failure, additionalProperties={}).


Results :

Tests in error: 
  OpenShiftIT.io.openshift.booster.OpenShiftIT » Runtime io.fabric8.kubernetes.c...

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

When I run:

mvn clean fabric8:deploy -Popenshift
mvn verify -Popenshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=false

It works fine.

Expected Behaviour

Integration test deploys its resources and test them

Current Behaviour

Integration test fails to deploy its resources.

Steps To Reproduce
  1. clone this maven project
  2. Checkout branch arquillian-cube-integration-test-openshift
  3. run mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=true
@RadekKoubsky

This comment has been minimized.

Show comment
Hide comment
@RadekKoubsky

RadekKoubsky Aug 10, 2017

I have tried the code with Arquillian Cube 1.8.0, the issue with image stream is still present.

RadekKoubsky commented Aug 10, 2017

I have tried the code with Arquillian Cube 1.8.0, the issue with image stream is still present.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

@RadekKoubsky I have started working on this. Any thought where the error could happen? I am asking just to not going completely blind.

Member

lordofthejars commented Sep 6, 2017

@RadekKoubsky I have started working on this. Any thought where the error could happen? I am asking just to not going completely blind.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

@RadekKoubsky I have been reading the issue and running the example and I have noticed that I am not sure if an error on Cube or if you have another scenario in mind but look when you do:

mvn clean fabric8:deploy -Popenshift
mvn verify -Popenshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=false

It works. And it works because fabric8:deploy generates the kubernetes resource and deploy it to OpenShift and then test is run, and since everything is deployed it works.

Then you say that using just thins command:

mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=true

Does not work. Basically it does not work because Arquillian is not deploying the scenario, but here is my question. There is no really advantage of using first instead of second approach. In terms of CI/CD it doesn't care since it is Jenkinsfile who does everything. In terms of development in terminal, well he can create a shell script and run it from build tool (Maven), create an alias or whatever. Then there is if developer is running from IDE, in this case is where it is interesting that Arquillian could deploy the services but you still need the manual step of generating the kubernetes file, so again if you need a manual step, it is not so automatic at all.

The only thing I see is that you can generate kubernetes file with maven call then switch to IDE and run the test from there, but then not sure it is valid from UX.

Am I missing something?

Member

lordofthejars commented Sep 6, 2017

@RadekKoubsky I have been reading the issue and running the example and I have noticed that I am not sure if an error on Cube or if you have another scenario in mind but look when you do:

mvn clean fabric8:deploy -Popenshift
mvn verify -Popenshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=false

It works. And it works because fabric8:deploy generates the kubernetes resource and deploy it to OpenShift and then test is run, and since everything is deployed it works.

Then you say that using just thins command:

mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=my-project -Denv.init.enabled=true

Does not work. Basically it does not work because Arquillian is not deploying the scenario, but here is my question. There is no really advantage of using first instead of second approach. In terms of CI/CD it doesn't care since it is Jenkinsfile who does everything. In terms of development in terminal, well he can create a shell script and run it from build tool (Maven), create an alias or whatever. Then there is if developer is running from IDE, in this case is where it is interesting that Arquillian could deploy the services but you still need the manual step of generating the kubernetes file, so again if you need a manual step, it is not so automatic at all.

The only thing I see is that you can generate kubernetes file with maven call then switch to IDE and run the test from there, but then not sure it is valid from UX.

Am I missing something?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

@lordofthejars The correct one to speak to is @spisiakm, as @RadekKoubsky is leaving Red Hat.

Actually the 1st scenario, the one with 2 Maven invocations, is something we don't want. We want the second one to work, the one with a single Maven invocation.

Contributor

Ladicek commented Sep 6, 2017

@lordofthejars The correct one to speak to is @spisiakm, as @RadekKoubsky is leaving Red Hat.

Actually the 1st scenario, the one with 2 Maven invocations, is something we don't want. We want the second one to work, the one with a single Maven invocation.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

Ok great, welcome @spisiakm, but what is the benefit of the second one if you still need one manual step?

Member

lordofthejars commented Sep 6, 2017

Ok great, welcome @spisiakm, but what is the benefit of the second one if you still need one manual step?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

Sorry, not sure I'm following. Here's a somewhat more recent description of the issue: fabric8-launcher/launcher-planning#43 (comment)

Basically, we need mvn clean verify to work, in an existing namespace. Are we doing something wrong?

Contributor

Ladicek commented Sep 6, 2017

Sorry, not sure I'm following. Here's a somewhat more recent description of the issue: fabric8-launcher/launcher-planning#43 (comment)

Basically, we need mvn clean verify to work, in an existing namespace. Are we doing something wrong?

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

but why not mvn fabric8:deploy verify -D..... ?

Member

lordofthejars commented Sep 6, 2017

but why not mvn fabric8:deploy verify -D..... ?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

Arquillian Cube is supposed to deploy the application, no? I'm pretty sure I'm missing something.

Contributor

Ladicek commented Sep 6, 2017

Arquillian Cube is supposed to deploy the application, no? I'm pretty sure I'm missing something.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

Yes when it is necessary (basically when you want to run your application from IDE or from CLI), basically when you create manually your kubernetes.json then it has sense to do it. But in this application you are not creating any kubernetes.json manually, you are letting fabric8 plugin to do it, so it means that you need to run at least one time (until you clean the project) the maven goal to generate these resources.

What I am saying is that if you want to run your tests from Maven, you don't need that Arquillian deploys anything you can just run mvn fabric8:deploy verify -D..... and that's all. Why would you need Arquillian does anything?

The other thing which might be more useful might be an integration between fabric8 plugin and arquillian so you can run safely from IDE and from CLI without worrying about calling the plugin first.

But this is a big change overall and I would like to listen comments about it from @bartoszmajsak and @iocanel and @jwendell

Member

lordofthejars commented Sep 6, 2017

Yes when it is necessary (basically when you want to run your application from IDE or from CLI), basically when you create manually your kubernetes.json then it has sense to do it. But in this application you are not creating any kubernetes.json manually, you are letting fabric8 plugin to do it, so it means that you need to run at least one time (until you clean the project) the maven goal to generate these resources.

What I am saying is that if you want to run your tests from Maven, you don't need that Arquillian deploys anything you can just run mvn fabric8:deploy verify -D..... and that's all. Why would you need Arquillian does anything?

The other thing which might be more useful might be an integration between fabric8 plugin and arquillian so you can run safely from IDE and from CLI without worrying about calling the plugin first.

But this is a big change overall and I would like to listen comments about it from @bartoszmajsak and @iocanel and @jwendell

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

@Ladicek if you want we can move the conversation to BJN as well.

Member

lordofthejars commented Sep 6, 2017

@Ladicek if you want we can move the conversation to BJN as well.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

So, in the linked repo, if I do mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=true, the fabric8:resource and fabric8:build goals run and the {kubernetes,openshift}.{json,yml} files are created long before the test starts. So I expect Arquillian to take them, apply them, run the test, then cleanup.

You ask: why do you want to do this? Well I ask: why not? It's simpler, it's how Maven is typically used, and if I understand the docs correctly, it should work. And it seems it would, but the image stream created by fabric8:build gets deleted for some reason. Is Arquillian possibly doing some pre-test cleanup?

Contributor

Ladicek commented Sep 6, 2017

So, in the linked repo, if I do mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=true, the fabric8:resource and fabric8:build goals run and the {kubernetes,openshift}.{json,yml} files are created long before the test starts. So I expect Arquillian to take them, apply them, run the test, then cleanup.

You ask: why do you want to do this? Well I ask: why not? It's simpler, it's how Maven is typically used, and if I understand the docs correctly, it should work. And it seems it would, but the image stream created by fabric8:build gets deleted for some reason. Is Arquillian possibly doing some pre-test cleanup?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

Oh thanks for the BJN offer, but I'm not very familiar with this issue, so unless you are fine with making it a pair debugging session, it wouldn't work :-)

Contributor

Ladicek commented Sep 6, 2017

Oh thanks for the BJN offer, but I'm not very familiar with this issue, so unless you are fine with making it a pair debugging session, it wouldn't work :-)

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

Exactly we can do this thing you mention but you could do mvn clean fabric8:deploy verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=false and you'll get the same, what I mean is why do you want that Arquillian deploys something generated by Maven plugin when the Maven plugin itself can do it.

Member

lordofthejars commented Sep 6, 2017

Exactly we can do this thing you mention but you could do mvn clean fabric8:deploy verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=false and you'll get the same, what I mean is why do you want that Arquillian deploys something generated by Maven plugin when the Maven plugin itself can do it.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

Well, at the very least, I don't want to force users to add more commands to the cmdline, when the traditional mvn clean verify obviously should work.

But out of curiosity, I tried mvn clean fabric8:deploy verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=false on the linked repo, and fabric8:deploy doesn't even get a chance to run, because tests are executed first.

Contributor

Ladicek commented Sep 6, 2017

Well, at the very least, I don't want to force users to add more commands to the cmdline, when the traditional mvn clean verify obviously should work.

But out of curiosity, I tried mvn clean fabric8:deploy verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=false on the linked repo, and fabric8:deploy doesn't even get a chance to run, because tests are executed first.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 6, 2017

Member

humm ok then tomorrow morning I will take a look what you should do to make it work and provide you the CLI option to do it.

Member

lordofthejars commented Sep 6, 2017

humm ok then tomorrow morning I will take a look what you should do to make it work and provide you the CLI option to do it.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 6, 2017

Contributor

Thank you!

Contributor

Ladicek commented Sep 6, 2017

Thank you!

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 7, 2017

Member

We have discussed potential solutions for this functionality with @lordofthejars.

Quick win

To let you guys use one mvn command to run everything we will fix Cube to scan for files generated by fabric8-maven-plugin. @lordofthejars is on it.

Desired improvement

We have two options here if we consider use case when you run the test from the IDE. We need to have those {kubernetes,openshift}.{json,yml} files generated upfront.

  • we can re-use logic of fabric8-maven-plugin to
    • generate those files
    • create s2i image and register it in openshift registry
    • this can be done under the hood based on e.g. @AutogenerateOpenshiftResources annotation put on the test class
  • we can provide Shrinkwrap descriptors so you can either create default files like fmp does but also open it up for customization "shrinkwrap style"
    • this would mean we have to flesh out what kind of @Deployment methods we would like to have to make it simple and powerful enough

Thoughts?

Member

bartoszmajsak commented Sep 7, 2017

We have discussed potential solutions for this functionality with @lordofthejars.

Quick win

To let you guys use one mvn command to run everything we will fix Cube to scan for files generated by fabric8-maven-plugin. @lordofthejars is on it.

Desired improvement

We have two options here if we consider use case when you run the test from the IDE. We need to have those {kubernetes,openshift}.{json,yml} files generated upfront.

  • we can re-use logic of fabric8-maven-plugin to
    • generate those files
    • create s2i image and register it in openshift registry
    • this can be done under the hood based on e.g. @AutogenerateOpenshiftResources annotation put on the test class
  • we can provide Shrinkwrap descriptors so you can either create default files like fmp does but also open it up for customization "shrinkwrap style"
    • this would mean we have to flesh out what kind of @Deployment methods we would like to have to make it simple and powerful enough

Thoughts?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 7, 2017

Contributor

Re "Quick win": my understanding from this section of the documentation is that Arquillian Cube should already be able to find the FMP-generated files. Am I wrong here? I'd consider this a bugfix, not an improvement. Actually you're using the word "fix" too, so it seems we're on the same page :-)

Re "Desired improvement": I don't think we considered running tests from IDE just yet :-) I think all our Kubernetes/OpenShift tooling revolves around FMP, so the 1st option sounds best to me. But I don't have all the details, I might be easily missing something.

And thanks for paying attention to this, it's gonna be a huge help for us!

Contributor

Ladicek commented Sep 7, 2017

Re "Quick win": my understanding from this section of the documentation is that Arquillian Cube should already be able to find the FMP-generated files. Am I wrong here? I'd consider this a bugfix, not an improvement. Actually you're using the word "fix" too, so it seems we're on the same page :-)

Re "Desired improvement": I don't think we considered running tests from IDE just yet :-) I think all our Kubernetes/OpenShift tooling revolves around FMP, so the 1st option sounds best to me. But I don't have all the details, I might be easily missing something.

And thanks for paying attention to this, it's gonna be a huge help for us!

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 7, 2017

Member

Ok, let's make the "Quick win" working then and we can discuss IDE experience when you will be focusing on it. I think we have a bug here which @lordofthejars is looking at.

And thanks for paying attention to this, it's gonna be a huge help for us!

Sure, our pleasure :)

Member

bartoszmajsak commented Sep 7, 2017

Ok, let's make the "Quick win" working then and we can discuss IDE experience when you will be focusing on it. I think we have a bug here which @lordofthejars is looking at.

And thanks for paying attention to this, it's gonna be a huge help for us!

Sure, our pleasure :)

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

We have found the root cause. Currently fabric8 plugin generate resources at target/classes/META-INF/fabric8 classpath location. The problem is that surefire plugin does not add target/classes but target/test-classes ("surefire.test.class.path" -> "/Users/alex/git/rest_springboot-tomcat/target/test-classes:/Users/alex/git/rest_springboot-tomcat/target/spring-boot-http-7-SNAPSHOT.jar:/Users/alex/.m2/repository/org/apache/tomcat/tomcat-juli/8.0.36/tomcat-juli-8.0.36.jar:..." so for Arquillian is impossible to find these files.

What we are going to do is talk with fabric8 guys to see if the plugin can copy resources in both places.

Member

lordofthejars commented Sep 8, 2017

We have found the root cause. Currently fabric8 plugin generate resources at target/classes/META-INF/fabric8 classpath location. The problem is that surefire plugin does not add target/classes but target/test-classes ("surefire.test.class.path" -> "/Users/alex/git/rest_springboot-tomcat/target/test-classes:/Users/alex/git/rest_springboot-tomcat/target/spring-boot-http-7-SNAPSHOT.jar:/Users/alex/.m2/repository/org/apache/tomcat/tomcat-juli/8.0.36/tomcat-juli-8.0.36.jar:..." so for Arquillian is impossible to find these files.

What we are going to do is talk with fabric8 guys to see if the plugin can copy resources in both places.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

That sounds weird. Per http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html, the target/classes directory is on test classpath. Is that maybe a Surefire/Failsafe bug? Let me check.

Contributor

Ladicek commented Sep 8, 2017

That sounds weird. Per http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html, the target/classes directory is on test classpath. Is that maybe a Surefire/Failsafe bug? Let me check.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

Currently you are using failsafe which should work in same way, but checking all resources loaded debugging the code we saw that the resources of target/classes are not there and also surefire.test.class.path only contains test-classes place. Then we moved the generated files there and they were found by Cube.

Member

lordofthejars commented Sep 8, 2017

Currently you are using failsafe which should work in same way, but checking all resources loaded debugging the code we saw that the resources of target/classes are not there and also surefire.test.class.path only contains test-classes place. Then we moved the generated files there and they were found by Cube.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek
Contributor

Ladicek commented Sep 8, 2017

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 8, 2017

Member

Documentation is apparently wrong. In the surefire.test.class.path property, passed to Failsafe Runner, what you are getting is a reference to a jar file with your production code, but not target/classes. And apparently files generated by fabric8-maven-plugin land in META-INF after this jar is produced.

Member

bartoszmajsak commented Sep 8, 2017

Documentation is apparently wrong. In the surefire.test.class.path property, passed to Failsafe Runner, what you are getting is a reference to a jar file with your production code, but not target/classes. And apparently files generated by fabric8-maven-plugin land in META-INF after this jar is produced.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

Ah, I see! That's again the thing with Failsafe preferring to use the JAR instead of target/classes!

Contributor

Ladicek commented Sep 8, 2017

Ah, I see! That's again the thing with Failsafe preferring to use the JAR instead of target/classes!

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

OK, so if I downgrade to Failsafe 2.18.1, which still uses target/classes, I get further. The test fails when trying to apply target/spring-boot-http-is.yml with an error message of:

imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:cf768ac1152974a20a08a34c76066a97137a1f0c29c1d57215dad183b9215b3b

This image did exist before the test started, as it was created by the Fabric8 Maven plugin. I can see it in the OpenShift web console. I don't know who deleted it -- was it Arquillian Cube?

(This finding is consistent with the issue description in fabric8-launcher/launcher-planning#43 (comment))

Contributor

Ladicek commented Sep 8, 2017

OK, so if I downgrade to Failsafe 2.18.1, which still uses target/classes, I get further. The test fails when trying to apply target/spring-boot-http-is.yml with an error message of:

imagestreams "spring-boot-http" is invalid: spec.tags[latest].from.name: Invalid value: "spring-boot-http@sha256:cf768ac1152974a20a08a34c76066a97137a1f0c29c1d57215dad183b9215b3b

This image did exist before the test started, as it was created by the Fabric8 Maven plugin. I can see it in the OpenShift web console. I don't know who deleted it -- was it Arquillian Cube?

(This finding is consistent with the issue description in fabric8-launcher/launcher-planning#43 (comment))

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

The problem here is that fabric8 executes this -is.yml file, and then in cube we are rexecuting again and you get this failure. In fact if you use CLI you'll get the same error. Figuring out how to fix this.

Member

lordofthejars commented Sep 8, 2017

The problem here is that fabric8 executes this -is.yml file, and then in cube we are rexecuting again and you get this failure. In fact if you use CLI you'll get the same error. Figuring out how to fix this.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

I think you can easily apply the same file twice. The issue seems to be that FMP creates the image, the image stream and the image stream tag, then someone deletes it all, and then Cube tries to apply the -is.yml file, which tries to create the image stream and the image stream tag, but the image is missing.

Anyway, great we're on the same page! :-)

Contributor

Ladicek commented Sep 8, 2017

I think you can easily apply the same file twice. The issue seems to be that FMP creates the image, the image stream and the image stream tag, then someone deletes it all, and then Cube tries to apply the -is.yml file, which tries to create the image stream and the image stream tag, but the image is missing.

Anyway, great we're on the same page! :-)

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

exactly this is what is happening, now I have commented the code in cube that detects -is.yml files and it has been able to deploy everything. So this is a really good step forward, so I need to think a bit but maybe we will make this -is.yml detection code optional being default to false.

cc/ @bartoszmajsak @dipak-pawar

Member

lordofthejars commented Sep 8, 2017

exactly this is what is happening, now I have commented the code in cube that detects -is.yml files and it has been able to deploy everything. So this is a really good step forward, so I need to think a bit but maybe we will make this -is.yml detection code optional being default to false.

cc/ @bartoszmajsak @dipak-pawar

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

Great! I'm just wondering, who and why deletes the image+imagestream+imagestreamtag? That shouldn't happen, should it?

Contributor

Ladicek commented Sep 8, 2017

Great! I'm just wondering, who and why deletes the image+imagestream+imagestreamtag? That shouldn't happen, should it?

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

Also, instead of downgrading to Failsafe 2.18.1, adding this to the Failsafe plugin configuration seems to work:

<configuration>
    <additionalClasspathElements>
        <additionalClasspathElement>${project.build.outputDirectory}/META-INF/fabric8</additionalClasspathElement>
    </additionalClasspathElements>
</configuration>
Contributor

Ladicek commented Sep 8, 2017

Also, instead of downgrading to Failsafe 2.18.1, adding this to the Failsafe plugin configuration seems to work:

<configuration>
    <additionalClasspathElements>
        <additionalClasspathElement>${project.build.outputDirectory}/META-INF/fabric8</additionalClasspathElement>
    </additionalClasspathElements>
</configuration>
@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

Good news I have got a running version of the project. I will add a new flag, and release 1.9.0 version of cube which by default will ignore the -is.yml files.

Member

lordofthejars commented Sep 8, 2017

Good news I have got a running version of the project. I will add a new flag, and release 1.9.0 version of cube which by default will ignore the -is.yml files.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

Cool! Any idea why the image gets deleted and applying the -is.yml file subsequently fails? I still don't quite understand why that happens.

Contributor

Ladicek commented Sep 8, 2017

Cool! Any idea why the image gets deleted and applying the -is.yml file subsequently fails? I still don't quite understand why that happens.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

I think that it is not really delated at all, for what we have seen is that is trying to create resources twice. Look if you want to try by yourself do this. mvn clean package and then go to target directory and do oc create -f ...-is.yml and you'll get the same error.

Member

lordofthejars commented Sep 8, 2017

I think that it is not really delated at all, for what we have seen is that is trying to create resources twice. Look if you want to try by yourself do this. mvn clean package and then go to target directory and do oc create -f ...-is.yml and you'll get the same error.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 8, 2017

Contributor

Well you're right, oc create -f ...-is.yml indeed also fails with error generating tag event: imagestreamimage.image.openshift.io "sha256:469b67311d56220795dec3c7a39ef2d9f61cd9d2cc25cca99752fb1cee2a0ebb" not found. That "not found" bit fooled me.

Contributor

Ladicek commented Sep 8, 2017

Well you're right, oc create -f ...-is.yml indeed also fails with error generating tag event: imagestreamimage.image.openshift.io "sha256:469b67311d56220795dec3c7a39ef2d9f61cd9d2cc25cca99752fb1cee2a0ebb" not found. That "not found" bit fooled me.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 8, 2017

Member

yes I think that it is more how OpenShift treat this scenario more than something related to our stuff.

Member

lordofthejars commented Sep 8, 2017

yes I think that it is more how OpenShift treat this scenario more than something related to our stuff.

@spisiakm

This comment has been minimized.

Show comment
Hide comment
@spisiakm

spisiakm Sep 11, 2017

Contributor

Thanks a lot @bartoszmajsak @lordofthejars for looking into this and also @Ladicek for substituting me in this case, unfortunately I wasn't available last week. I'm going try it out and see what happens. @Ladicek has already tried this out with Spring Boot http booster and it worked just fine, so thank you again, you helped us quite a bit ! :)

Contributor

spisiakm commented Sep 11, 2017

Thanks a lot @bartoszmajsak @lordofthejars for looking into this and also @Ladicek for substituting me in this case, unfortunately I wasn't available last week. I'm going try it out and see what happens. @Ladicek has already tried this out with Spring Boot http booster and it worked just fine, so thank you again, you helped us quite a bit ! :)

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 11, 2017

Member

Just give us go/no-go and we will proceed accordingly :)

Member

bartoszmajsak commented Sep 11, 2017

Just give us go/no-go and we will proceed accordingly :)

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 11, 2017

Contributor

Unfortunately, this isn't enough yet :-( It works flawlessly when running tests in an existing project (which is our main usecase), but running in an Arquillian-created project doesn't work (which, obviously, is needed for OpenShift.io).

  1. mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=true works
  2. mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true doesn't work, the build gets stuck at Applying kubernetes configuration from: jar:file:/home/lthon/tmp/rest_springboot-tomcat/target/spring-boot-http-7-SNAPSHOT.jar!/META-INF/fabric8/openshift.json, no pod is running in the itest-xxxxx namespace, presumably because the image was build in another namespace?
  3. mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true doesn't work, the test fails with java.lang.RuntimeException: io.fabric8.kubernetes.clnt.v2_6.KubernetesClientException: Failure executing: POST at: https://192.168.0.100:8443/oapi/v1/namespaces/itest-6785a55b/imagestreams. Message: ImageStream "spring-boot-http" is invalid, which seems to be the same error message this all started with.

Sounds like we're back to square 1?

Contributor

Ladicek commented Sep 11, 2017

Unfortunately, this isn't enough yet :-( It works flawlessly when running tests in an existing project (which is our main usecase), but running in an Arquillian-created project doesn't work (which, obviously, is needed for OpenShift.io).

  1. mvn clean verify -Popenshift,openshift-it -Dnamespace.use.existing=myproject -Denv.init.enabled=true works
  2. mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true doesn't work, the build gets stuck at Applying kubernetes configuration from: jar:file:/home/lthon/tmp/rest_springboot-tomcat/target/spring-boot-http-7-SNAPSHOT.jar!/META-INF/fabric8/openshift.json, no pod is running in the itest-xxxxx namespace, presumably because the image was build in another namespace?
  3. mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true doesn't work, the test fails with java.lang.RuntimeException: io.fabric8.kubernetes.clnt.v2_6.KubernetesClientException: Failure executing: POST at: https://192.168.0.100:8443/oapi/v1/namespaces/itest-6785a55b/imagestreams. Message: ImageStream "spring-boot-http" is invalid, which seems to be the same error message this all started with.

Sounds like we're back to square 1?

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 11, 2017

Member
Member

lordofthejars commented Sep 11, 2017

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 11, 2017

Contributor

Indeed Fabric8 Maven plugin creates the image stream, but in a different namespace than the itest-xxxxx. So I was thinking I need to enable adding the image stream to the itest-xxxx namespace, and that seems to work manually.

Contributor

Ladicek commented Sep 11, 2017

Indeed Fabric8 Maven plugin creates the image stream, but in a different namespace than the itest-xxxxx. So I was thinking I need to enable adding the image stream to the itest-xxxx namespace, and that seems to work manually.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 11, 2017

Member
Member

lordofthejars commented Sep 11, 2017

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 12, 2017

Contributor

BTW, here's what I did to verify the behavior in the 3rd case (all with a snapshot build of current Cube master):

mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true -Dnamespace.cleanup.enabled=false -Dnamespace.destroy.enabled=false
# this fails with java.lang.RuntimeException: io.fabric8.kubernetes.clnt.v2_6.KubernetesClientException: Failure executing: POST at: https://192.168.0.100:8443/oapi/v1/namespaces/itest-4d3cff0b/imagestreams. Message: ImageStream "spring-boot-http" is invalid

oc get project
oc project itest-xxxxx

oc create -f target/spring-boot-http-is.yml
# this works just fine, and actually allows the deployment created by Cube before the test to proceed
Contributor

Ladicek commented Sep 12, 2017

BTW, here's what I did to verify the behavior in the 3rd case (all with a snapshot build of current Cube master):

mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true -Dnamespace.cleanup.enabled=false -Dnamespace.destroy.enabled=false
# this fails with java.lang.RuntimeException: io.fabric8.kubernetes.clnt.v2_6.KubernetesClientException: Failure executing: POST at: https://192.168.0.100:8443/oapi/v1/namespaces/itest-4d3cff0b/imagestreams. Message: ImageStream "spring-boot-http" is invalid

oc get project
oc project itest-xxxxx

oc create -f target/spring-boot-http-is.yml
# this works just fine, and actually allows the deployment created by Cube before the test to proceed
@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 12, 2017

Contributor

Also, I've been successful with porting a WildFly Swarm booster test to Arquillian Cube (found #803 in the process), but I stumbled upon this roadblock: https://github.com/Ladicek/wfswarm-rest-http/blob/arquillian-cube/src/test/java/io/openshift/booster/GreetingServiceTest.java#L37 Do you possibly know of any solution? Thanks!

Contributor

Ladicek commented Sep 12, 2017

Also, I've been successful with porting a WildFly Swarm booster test to Arquillian Cube (found #803 in the process), but I stumbled upon this roadblock: https://github.com/Ladicek/wfswarm-rest-http/blob/arquillian-cube/src/test/java/io/openshift/booster/GreetingServiceTest.java#L37 Do you possibly know of any solution? Thanks!

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 13, 2017

Member

Hi @Ladicek about the second and third case that it is not working, this is related on how it works Cube and fabric8. What Fabric8 Maven plugin does is create and configure some stuff inside the default OpenShift namespace (ie myproject). And this occurs before Cube test is executed. Then Cube test is executed and it creates a random namespace (it-....) but this new namespace has not the content generated by fabric8 maven plugin previously, so when the -is.yml is executed it fails because it misses some content.

The solution for that requires some big development, basically an integration between Fabric8 and Cube like explained here #743 (comment) so fabric8 bits are executed after the random namespace is created by cube.

Member

lordofthejars commented Sep 13, 2017

Hi @Ladicek about the second and third case that it is not working, this is related on how it works Cube and fabric8. What Fabric8 Maven plugin does is create and configure some stuff inside the default OpenShift namespace (ie myproject). And this occurs before Cube test is executed. Then Cube test is executed and it creates a random namespace (it-....) but this new namespace has not the content generated by fabric8 maven plugin previously, so when the -is.yml is executed it fails because it misses some content.

The solution for that requires some big development, basically an integration between Fabric8 and Cube like explained here #743 (comment) so fabric8 bits are executed after the random namespace is created by cube.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 13, 2017

Member

@Ladicek I don't understand exactly the problem, but if the problem is just enable tests in failsafe and not surefire, the only thing I guess you can do is playing with inclusions/exclusions in surefire plugin and failsafe plugin cc/ @bartoszmajsak

Member

lordofthejars commented Sep 13, 2017

@Ladicek I don't understand exactly the problem, but if the problem is just enable tests in failsafe and not surefire, the only thing I guess you can do is playing with inclusions/exclusions in surefire plugin and failsafe plugin cc/ @bartoszmajsak

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars
Member

lordofthejars commented Sep 13, 2017

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 13, 2017

Contributor

Hi @lordofthejars, when it comes to the -is.yml thing, I think this should easily work, because the -is.yml contains a namespace, so when importing it to itest-xxxx, the image should be found just fine. And indeed when trying it manually, it works -- as described in #743 (comment)

When it comes to the second problem (when Cube is used in a Surefire test run) -- ah you are actually right, I can easily exclude Cube from test classpath with Surefire! THANKS A LOT! Funny I didn't think of it myself, as I've been dealing with test classpath exclusions just a while ago :-)

Contributor

Ladicek commented Sep 13, 2017

Hi @lordofthejars, when it comes to the -is.yml thing, I think this should easily work, because the -is.yml contains a namespace, so when importing it to itest-xxxx, the image should be found just fine. And indeed when trying it manually, it works -- as described in #743 (comment)

When it comes to the second problem (when Cube is used in a Surefire test run) -- ah you are actually right, I can easily exclude Cube from test classpath with Surefire! THANKS A LOT! Funny I didn't think of it myself, as I've been dealing with test classpath exclusions just a while ago :-)

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 13, 2017

Member

Humm I tried with @dipak-pawar and it failed using oc. I'll continue investigating on this too, because in my case it failed as well.

Member

lordofthejars commented Sep 13, 2017

Humm I tried with @dipak-pawar and it failed using oc. I'll continue investigating on this too, because in my case it failed as well.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 13, 2017

Contributor

Hmm weird. I'll check again.

Contributor

Ladicek commented Sep 13, 2017

Hmm weird. I'll check again.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 13, 2017

Member

I have talked with @rhuss today and it seems that this use case should not be working by default if you are not pointing fabric8 and cube into same namespace.

Member

lordofthejars commented Sep 13, 2017

I have talked with @rhuss today and it seems that this use case should not be working by default if you are not pointing fabric8 and cube into same namespace.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 13, 2017

Contributor

So basically the ability of Cube to create a separate namespace is known to not work when using Fabric8 Maven plugin? That's unfortunate.

Contributor

Ladicek commented Sep 13, 2017

So basically the ability of Cube to create a separate namespace is known to not work when using Fabric8 Maven plugin? That's unfortunate.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 13, 2017

Member

It is not exactly like that I mean it is normal that this is happening since until now I am not sure that Cube was thought to be work together with fabric8 how we are doing now. Currently Fabric8 has its own bits and Cube their own. This means that Fabric8 does some stuff when it is run with the current namespace. On the other side Cube does some stuff on configured namespace which can be the current one or a new one. If you choose a new one, since a) Fabric8 runs before Cube and b) the namespace is generated randomly, we have no way to make it work with random stuff.

Tomorrow I'll try if there is any workaround, but as I suspect we will need to implement this integration so first Cube creates the namespace and second Fabric8 does its stuff and not the other way around.

Member

lordofthejars commented Sep 13, 2017

It is not exactly like that I mean it is normal that this is happening since until now I am not sure that Cube was thought to be work together with fabric8 how we are doing now. Currently Fabric8 has its own bits and Cube their own. This means that Fabric8 does some stuff when it is run with the current namespace. On the other side Cube does some stuff on configured namespace which can be the current one or a new one. If you choose a new one, since a) Fabric8 runs before Cube and b) the namespace is generated randomly, we have no way to make it work with random stuff.

Tomorrow I'll try if there is any workaround, but as I suspect we will need to implement this integration so first Cube creates the namespace and second Fabric8 does its stuff and not the other way around.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 13, 2017

Contributor

Thanks for info, @lordofthejars!

Contributor

Ladicek commented Sep 13, 2017

Thanks for info, @lordofthejars!

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 13, 2017

Contributor

I'm thinking we should probably open a new issue for the 2nd usecase (FMP + Arquillian Cube creating a new namespace), now that the 1st one works fine (FMP + Arquillian Cube running in current namespace). WDYT?

Contributor

Ladicek commented Sep 13, 2017

I'm thinking we should probably open a new issue for the 2nd usecase (FMP + Arquillian Cube creating a new namespace), now that the 1st one works fine (FMP + Arquillian Cube running in current namespace). WDYT?

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 14, 2017

Member

@Ladicek this is exactly what I wanted to talk with you on mattermost. The first thing is to try to define a priority, currently case 1 is covered and it is working, then case 2 and 3 are something that is currently widely used or something that is planed to be used (just to see if it is also a blocker, or it is something that can wait one week).

For second case I created a new issue #806 before starting implementing it, today I'll check if there is some quick workaround.

Member

lordofthejars commented Sep 14, 2017

@Ladicek this is exactly what I wanted to talk with you on mattermost. The first thing is to try to define a priority, currently case 1 is covered and it is working, then case 2 and 3 are something that is currently widely used or something that is planed to be used (just to see if it is also a blocker, or it is something that can wait one week).

For second case I created a new issue #806 before starting implementing it, today I'll check if there is some quick workaround.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 14, 2017

Contributor

@lordofthejars Sorry, I don't frequent Mattermost, it's like a 5th chat I'd have to figure out... but if you ping me there, I can join.

The cases 2/3 -- well we don't need them at the moment, I believe, but it will become important soon because of OpenShift.io. So waiting one or two weeks should be OK.

Contributor

Ladicek commented Sep 14, 2017

@lordofthejars Sorry, I don't frequent Mattermost, it's like a 5th chat I'd have to figure out... but if you ping me there, I can join.

The cases 2/3 -- well we don't need them at the moment, I believe, but it will become important soon because of OpenShift.io. So waiting one or two weeks should be OK.

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
@bartoszmajsak

bartoszmajsak Sep 14, 2017

Member

@Ladicek can you elaborate a bit on

but it will become important soon because of OpenShift.io

So with the fix 1. you can switch from OpenshiftTestAssistant to Cube, but those test will still not run on OSIO? openshiftio/booster-common#8

Member

bartoszmajsak commented Sep 14, 2017

@Ladicek can you elaborate a bit on

but it will become important soon because of OpenShift.io

So with the fix 1. you can switch from OpenshiftTestAssistant to Cube, but those test will still not run on OSIO? openshiftio/booster-common#8

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 14, 2017

Contributor

I keep hearing that we need to switch to Arquillian Cube because it allows running tests in a different namespace, which is needed on OpenShift.io: openshiftio/booster-common#8 I don't know if that's true or not, but assuming it is, then:

  1. We can switch to Cube for RHOAR boosters tests, because we run them in "current" namespace. Well I'm pretty sure we'll find issues along the way (one thing I can think of right now: can we deploy a configmap manually before Cube starts deploying resources?), but that's probably expected.
  2. We still won't be able to run RHOAR boosters tests on OpenShift.io, because running in a different namespace doesn't work.
Contributor

Ladicek commented Sep 14, 2017

I keep hearing that we need to switch to Arquillian Cube because it allows running tests in a different namespace, which is needed on OpenShift.io: openshiftio/booster-common#8 I don't know if that's true or not, but assuming it is, then:

  1. We can switch to Cube for RHOAR boosters tests, because we run them in "current" namespace. Well I'm pretty sure we'll find issues along the way (one thing I can think of right now: can we deploy a configmap manually before Cube starts deploying resources?), but that's probably expected.
  2. We still won't be able to run RHOAR boosters tests on OpenShift.io, because running in a different namespace doesn't work.
@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 14, 2017

Member

configmap manually

yes if you do it either manually before running mvn or in maven lifecycle before integration tests.

Member

lordofthejars commented Sep 14, 2017

configmap manually

yes if you do it either manually before running mvn or in maven lifecycle before integration tests.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 14, 2017

Contributor

That's exactly what I hoped I won't hear :-) But we'll figure it out when we get there.

Contributor

Ladicek commented Sep 14, 2017

That's exactly what I hoped I won't hear :-) But we'll figure it out when we get there.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 14, 2017

Member

or you can create an openshift additional file and configure cube to pick it up, but let's wait when it is required.

Member

lordofthejars commented Sep 14, 2017

or you can create an openshift additional file and configure cube to pick it up, but let's wait when it is required.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 18, 2017

Member

@Ladicek check latest master because the problem described in 3) should be fixed.
Notice that the use case number 2, is not valid here because fabric8 with OpenShift requires an ImageStream insert on given namespace. If you don't set the enableImageStreamDetection to true then Cube never inserts the ImageStream so the test will fail because it misses one part (the Image Stream part).

So I think that now everything is fixed. Just give a try.

Member

lordofthejars commented Sep 18, 2017

@Ladicek check latest master because the problem described in 3) should be fixed.
Notice that the use case number 2, is not valid here because fabric8 with OpenShift requires an ImageStream insert on given namespace. If you don't set the enableImageStreamDetection to true then Cube never inserts the ImageStream so the test will fail because it misses one part (the Image Stream part).

So I think that now everything is fixed. Just give a try.

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 18, 2017

Member

More about second case notice that in case 2 you are running mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true and in case 3 mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true since you want to use openshift.json and this file requires an ImageStream there, if you don't set the the flag to true when deploying the openshift.json you'll get an error (as it is happening). So the rule of thumb here is that if you are using OpenShift with ImageStreams (by default in F8 Maven Plugin are used) you need to set the enableImageStreamDetection flag to true or it won't work because of missing pieces on tested namespace.

Of course this do not apply when you are using the same namespace as used in F8 Maven plugin (case 1)

Member

lordofthejars commented Sep 18, 2017

More about second case notice that in case 2 you are running mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true and in case 3 mvn clean verify -Popenshift,openshift-it -Denv.init.enabled=true -DenableImageStreamDetection=true since you want to use openshift.json and this file requires an ImageStream there, if you don't set the the flag to true when deploying the openshift.json you'll get an error (as it is happening). So the rule of thumb here is that if you are using OpenShift with ImageStreams (by default in F8 Maven Plugin are used) you need to set the enableImageStreamDetection flag to true or it won't work because of missing pieces on tested namespace.

Of course this do not apply when you are using the same namespace as used in F8 Maven plugin (case 1)

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 19, 2017

Member

@spisiakm Have you had time to try with latest master of Arquillian Cube? In my computer the project using method 3 passed correctly.

Member

lordofthejars commented Sep 19, 2017

@spisiakm Have you had time to try with latest master of Arquillian Cube? In my computer the project using method 3 passed correctly.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 19, 2017

Contributor

Hi, indeed case 2 is wrong per current design and I expect it to fail. But case 3 definitely should work.

And I just verified that with current Cube master, case 3 works just fine. I think Cube currently covers the usecases we need (though I guess we'll find other issues as we progress :-) ).

@spisiakm, could you please also check and confirm? Thanks.

Contributor

Ladicek commented Sep 19, 2017

Hi, indeed case 2 is wrong per current design and I expect it to fail. But case 3 definitely should work.

And I just verified that with current Cube master, case 3 works just fine. I think Cube currently covers the usecases we need (though I guess we'll find other issues as we progress :-) ).

@spisiakm, could you please also check and confirm? Thanks.

@spisiakm

This comment has been minimized.

Show comment
Hide comment
@spisiakm

spisiakm Sep 19, 2017

Contributor

Hi folks,
case no. 3 works like a charm now with current master, so I guess this issue is resolved/fixed. Thanks a lot !

Contributor

spisiakm commented Sep 19, 2017

Hi folks,
case no. 3 works like a charm now with current master, so I guess this issue is resolved/fixed. Thanks a lot !

@lordofthejars

This comment has been minimized.

Show comment
Hide comment
@lordofthejars

lordofthejars Sep 19, 2017

Member

You are welcome, thank you very much for your feedback, since it is really valuable. Anything you need please ping us, since we are trying to give top priority.

Today I am going to release a new Arquillian Cube version so you have on maven central.

Member

lordofthejars commented Sep 19, 2017

You are welcome, thank you very much for your feedback, since it is really valuable. Anything you need please ping us, since we are trying to give top priority.

Today I am going to release a new Arquillian Cube version so you have on maven central.

@lordofthejars lordofthejars added this to the 1.9.0 milestone Sep 19, 2017

@lordofthejars lordofthejars self-assigned this Sep 19, 2017

@lordofthejars lordofthejars added the bug label Sep 19, 2017

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 19, 2017

Contributor

Thanks @lordofthejars, having these fixes in an actual release will be great! We realized we'll need to switch to Cube pretty soon, we'll get in touch if we hit an issue. Thanks!

Contributor

Ladicek commented Sep 19, 2017

Thanks @lordofthejars, having these fixes in an actual release will be great! We realized we'll need to switch to Cube pretty soon, we'll get in touch if we hit an issue. Thanks!

@bartoszmajsak

This comment has been minimized.

Show comment
Hide comment
Member

bartoszmajsak commented Sep 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment