From kohei at nozaki.me Sun May 1 01:28:21 2016 From: kohei at nozaki.me (Kohei Nozaki) Date: Sun, 1 May 2016 10:28:21 +0900 Subject: [kontinuity-dev-public] Integration test failure on catapult-service-openshift-impl In-Reply-To: References: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> Message-ID: <0b243ff6-b46e-e36a-cc0f-0536cf9f4caf@nozaki.me> Hi Andrew, Good news: I've just succeeded to run integration tests, in an all-in-one CentOS7 VM, Running tests in a VM is not comfortable though. The cause seems like some network layer problem because my first try was with a combo of OS X host (runs Catapult tests and WildFly) and CentOS7 guest (runs Docker and OpenShift) which is living in VMware Fusion. I followed this instruction to setup OpenShift: https://github.com/openshift/origin/blob/master/CONTRIBUTING.adoc#download-from-github But anyway I need to investigate how to make OS X + VM combo work before start working on the project. any hints about it would be greatly appreciated. Thanks, Kohei On 4/30/16 14:47, Andrew Lee Rubinger wrote: > Hey Kohel: > > Welcome! Though I haven't seen this error yet either locally or in our > CI environments, let's see what we can do. > > So the relevant error is in your connecting to OpenShift: > > io.fabric8.kubernetes.client.KubernetesClientException: An error has > occurred. > Caused by: java.io.IOException: unexpected end of stream on > com.squareup.okhttp.Address at e5a03a78 > Caused by: java.io.EOFException: \n not found: size=7 > content=15030100020216... > > I'm guessing you followed the instructions to get OpenShift running > locally; if you hadn't I think you'd be seeing some variant of > ConnectException: > > Caused by: io.fabric8.kubernetes.client.KubernetesClientException: An > error has occurred. > Caused by: java.net.ConnectException: Failed to connect to > localhost/127.0.0.1:8443 > > Can you let us know which method you've chosen to run OpenShift? I've > been testing here against a local build of OpenShift Origin master. > > Beyond that I see some similar complaints in the okhttp tracker: > > https://github.com/square/okhttp/issues/1741 > > ...perhaps the Fabric8 team has some better insights as they're > consuming the lib; will ping @iocanel. > > S, > ALR > > On Sat, Apr 30, 2016 at 7:42 AM, Kohei Nozaki > wrote: > > Hello, > > I'm trying to run Catapult's integration test cases following > README, but it doesn't work for me. > > Build log: > https://gist.github.com/lbtc-xxx/9aaddf84d11986e0dc84f979545a28e0 > > Relevant part of failsafe-reports: > http://people.apache.org/~kohei/failsafe-reports-openshift-service-impl/ > > I'm newbie of Docker / OpenShift so maybe it's caused by easy > mistake, but I don't know what it is. could you give me any hints to > make it work? > > Thanks. > > Kohei > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger From alr at redhat.com Sun May 1 02:58:51 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Sun, 1 May 2016 08:28:51 +0530 Subject: [kontinuity-dev-public] Integration test failure on catapult-service-openshift-impl In-Reply-To: <0b243ff6-b46e-e36a-cc0f-0536cf9f4caf@nozaki.me> References: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> <0b243ff6-b46e-e36a-cc0f-0536cf9f4caf@nozaki.me> Message-ID: Ah, that makes a lot of sense given that additional context; the tests are needing to reach the host; I wonder if exposing the ports you need from your VM to your host and then manually specifying the env var or sysprop KONTINUITY_CATAPULT_OPENSHIFT_URL should do it for you. Basically if you can run OpenShift in your VM and then from a brower/curl on your host execute requests against the VM-running OpenShift API, you should be good to go. S, ALR On Sun, May 1, 2016 at 6:58 AM, Kohei Nozaki wrote: > Hi Andrew, > > Good news: I've just succeeded to run integration tests, in an all-in-one > CentOS7 VM, Running tests in a VM is not comfortable though. > > The cause seems like some network layer problem because my first try was > with a combo of OS X host (runs Catapult tests and WildFly) and CentOS7 > guest (runs Docker and OpenShift) which is living in VMware Fusion. > > I followed this instruction to setup OpenShift: > > https://github.com/openshift/origin/blob/master/CONTRIBUTING.adoc#download-from-github > > But anyway I need to investigate how to make OS X + VM combo work before > start working on the project. any hints about it would be greatly > appreciated. > > Thanks, > > Kohei > > On 4/30/16 14:47, Andrew Lee Rubinger wrote: > >> Hey Kohel: >> >> Welcome! Though I haven't seen this error yet either locally or in our >> CI environments, let's see what we can do. >> >> So the relevant error is in your connecting to OpenShift: >> >> io.fabric8.kubernetes.client.KubernetesClientException: An error has >> occurred. >> Caused by: java.io.IOException: unexpected end of stream on >> com.squareup.okhttp.Address at e5a03a78 >> Caused by: java.io.EOFException: \n not found: size=7 >> content=15030100020216... >> >> I'm guessing you followed the instructions to get OpenShift running >> locally; if you hadn't I think you'd be seeing some variant of >> ConnectException: >> >> Caused by: io.fabric8.kubernetes.client.KubernetesClientException: An >> error has occurred. >> Caused by: java.net.ConnectException: Failed to connect to >> localhost/127.0.0.1:8443 >> >> Can you let us know which method you've chosen to run OpenShift? I've >> been testing here against a local build of OpenShift Origin master. >> >> Beyond that I see some similar complaints in the okhttp tracker: >> >> https://github.com/square/okhttp/issues/1741 >> >> ...perhaps the Fabric8 team has some better insights as they're >> consuming the lib; will ping @iocanel. >> >> S, >> ALR >> >> On Sat, Apr 30, 2016 at 7:42 AM, Kohei Nozaki > > wrote: >> >> Hello, >> >> I'm trying to run Catapult's integration test cases following >> README, but it doesn't work for me. >> >> Build log: >> https://gist.github.com/lbtc-xxx/9aaddf84d11986e0dc84f979545a28e0 >> >> Relevant part of failsafe-reports: >> >> http://people.apache.org/~kohei/failsafe-reports-openshift-service-impl/ >> >> I'm newbie of Docker / OpenShift so maybe it's caused by easy >> mistake, but I don't know what it is. could you give me any hints to >> make it work? >> >> Thanks. >> >> Kohei >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> >> >> >> -- >> Red Hat Developer Programs Architecture >> @ALRubinger >> > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From distortion-jenkins at redhat.com Sun May 1 06:03:01 2016 From: distortion-jenkins at redhat.com (distortion-jenkins at redhat.com) Date: Sun, 1 May 2016 06:03:01 +0000 (UTC) Subject: [kontinuity-dev-public] Build failed in Jenkins: catapult #13 Message-ID: <1223294909.9.1462082581741.JavaMail.root@jenkins-c7fj5> See ------------------------------------------ [...truncated 1035 lines...] [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/aether/aether-spi/1.0.0.v20140518/aether-spi-1.0.0.v20140518.jar (31 KB at 92.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/eclipse/aether/aether-transport-wagon/1.0.0.v20140518/aether-transport-wagon-1.0.0.v20140518.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/aether/aether-api/1.0.0.v20140518/aether-api-1.0.0.v20140518.jar (134 KB at 364.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.2.5/maven-aether-provider-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/aether/aether-transport-wagon/1.0.0.v20140518/aether-transport-wagon-1.0.0.v20140518.jar (25 KB at 62.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-model/3.2.5/maven-model-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/aether/aether-connector-basic/1.0.0.v20140518/aether-connector-basic-1.0.0.v20140518.jar (36 KB at 76.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.2.5/maven-model-builder-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar (143 KB at 297.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.2.5/maven-repository-metadata-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-model/3.2.5/maven-model-3.2.5.jar (158 KB at 305.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.2.5/maven-settings-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.2.5/maven-aether-provider-3.2.5.jar (65 KB at 124.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.2.5/maven-settings-builder-3.2.5.jar [INFO] Downloaded: http://nexus/content/groups/public/javax/javaee-api/7.0/javaee-api-7.0.jar (1886 KB at 3453.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/com/google/guava/guava/18.0/guava-18.0.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.2.5/maven-model-builder-3.2.5.jar (167 KB at 302.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.2.5/maven-repository-metadata-3.2.5.jar (26 KB at 45.4 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.2.5/maven-settings-builder-3.2.5.jar (43 KB at 76.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-provider-api/2.6/wagon-provider-api-2.6.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.2.5/maven-settings-3.2.5.jar (43 KB at 72.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-file/2.6/wagon-file-2.6.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-file/2.6/wagon-file-2.6.jar (12 KB at 17.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-lightweight/2.6/wagon-http-lightweight-2.6.jar [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar (238 KB at 365.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-shared/2.6/wagon-http-shared-2.6.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-provider-api/2.6/wagon-provider-api-2.6.jar (52 KB at 70.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jsoup/jsoup/1.7.2/jsoup-1.7.2.jar [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar (61 KB at 66.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-impl-maven-archive/2.2.1/shrinkwrap-resolver-impl-maven-archive-2.2.1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-lightweight/2.6/wagon-http-lightweight-2.6.jar (16 KB at 16.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-spi-maven-archive/2.2.1/shrinkwrap-resolver-spi-maven-archive-2.2.1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-shared/2.6/wagon-http-shared-2.6.jar (11 KB at 10.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.0.M1/org.eclipse.sisu.plexus-0.3.0.M1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jsoup/jsoup/1.7.2/jsoup-1.7.2.jar (287 KB at 294.4 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar [INFO] Downloaded: http://nexus/content/groups/public/com/google/guava/guava/18.0/guava-18.0.jar (2204 KB at 2218.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar [INFO] Downloaded: http://nexus/content/groups/public/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar (44 KB at 38.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/javax/inject/javax.inject/1/javax.inject-1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.0.M1/org.eclipse.sisu.plexus-0.3.0.M1.jar (196 KB at 172.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.0.M1/org.eclipse.sisu.inject-0.3.0.M1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-spi-maven-archive/2.2.1/shrinkwrap-resolver-spi-maven-archive-2.2.1.jar (6 KB at 5.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.3/plexus-compiler-javac-2.3.jar [INFO] Downloaded: http://nexus/content/groups/public/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar (6 KB at 4.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.3/plexus-compiler-api-2.3.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-impl-maven-archive/2.2.1/shrinkwrap-resolver-impl-maven-archive-2.2.1.jar (50 KB at 40.4 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-container/1.1.11.Final/arquillian-junit-container-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/javax/inject/javax.inject/1/javax.inject-1.jar (3 KB at 1.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-core/1.1.11.Final/arquillian-junit-core-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.0.M1/org.eclipse.sisu.inject-0.3.0.M1.jar (333 KB at 204.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-api/1.1.11.Final/arquillian-test-api-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.3/plexus-compiler-javac-2.3.jar (19 KB at 11.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-api/1.1.11.Final/arquillian-core-api-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.3/plexus-compiler-api-2.3.jar (25 KB at 15.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-spi/1.1.11.Final/arquillian-test-spi-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-container/1.1.11.Final/arquillian-junit-container-1.1.11.Final.jar (9 KB at 4.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-spi/1.1.11.Final/arquillian-core-spi-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-core/1.1.11.Final/arquillian-junit-core-1.1.11.Final.jar (38 KB at 21.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-api/1.1.11.Final/arquillian-container-test-api-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-spi/1.1.11.Final/arquillian-test-spi-1.1.11.Final.jar (41 KB at 21.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-spi/1.1.11.Final/arquillian-container-test-spi-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-api/1.1.11.Final/arquillian-core-api-1.1.11.Final.jar (10 KB at 4.9 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-api/1.1.11.Final/arquillian-test-api-1.1.11.Final.jar (4 KB at 1.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0-alpha-8/shrinkwrap-descriptors-api-base-2.0.0-alpha-8.jar [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-spi/1.1.11.Final/arquillian-container-spi-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-spi/1.1.11.Final/arquillian-core-spi-1.1.11.Final.jar (27 KB at 13.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-impl-base/1.1.11.Final/arquillian-core-impl-base-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-api/1.1.11.Final/arquillian-container-test-api-1.1.11.Final.jar (9 KB at 4.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-impl-base/1.1.11.Final/arquillian-test-impl-base-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0-alpha-8/shrinkwrap-descriptors-api-base-2.0.0-alpha-8.jar (17 KB at 8.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-impl-base/1.1.11.Final/arquillian-container-impl-base-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-spi/1.1.11.Final/arquillian-container-spi-1.1.11.Final.jar (51 KB at 24.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-api/1.1.11.Final/arquillian-config-api-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-spi/1.1.11.Final/arquillian-container-test-spi-1.1.11.Final.jar (26 KB at 11.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-impl-base/1.1.11.Final/arquillian-config-impl-base-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-impl-base/1.1.11.Final/arquillian-test-impl-base-1.1.11.Final.jar (28 KB at 12.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0-alpha-8/shrinkwrap-descriptors-spi-2.0.0-alpha-8.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-impl-base/1.1.11.Final/arquillian-core-impl-base-1.1.11.Final.jar (61 KB at 27.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-impl-base/1.1.11.Final/arquillian-container-test-impl-base-1.1.11.Final.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-impl-base/1.1.11.Final/arquillian-container-impl-base-1.1.11.Final.jar (78 KB at 35.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.3/shrinkwrap-impl-base-1.2.3.jar [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-api/1.1.11.Final/arquillian-config-api-1.1.11.Final.jar (8 KB at 3.3 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-impl-base/1.1.11.Final/arquillian-config-impl-base-1.1.11.Final.jar (41 KB at 18.1 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0-alpha-8/shrinkwrap-descriptors-spi-2.0.0-alpha-8.jar (38 KB at 16.7 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-impl-base/1.1.11.Final/arquillian-container-test-impl-base-1.1.11.Final.jar (107 KB at 47.6 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.3/shrinkwrap-impl-base-1.2.3.jar (187 KB at 83.2 KB/sec) [INFO] [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ catapult-base --- [INFO] Deleting /home/jenkins/workspace/workspace/catapult at 2/base/target [INFO] [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-java-version) @ catapult-base --- [INFO] [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @ catapult-base --- [INFO] [INFO] --- buildnumber-maven-plugin:1.4:create (get-scm-revision) @ catapult-base --- [INFO] [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ catapult-base --- [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.pom (7 KB at 138.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.pom (4 KB at 104.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom (5 KB at 94.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.12/plexus-interpolation-1.12.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.12/plexus-interpolation-1.12.pom (889 B at 21.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.pom (3 KB at 93.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/spice/spice-parent/10/spice-parent-10.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/spice/spice-parent/10/spice-parent-10.pom (3 KB at 73.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/forge/forge-parent/3/forge-parent-3.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/forge/forge-parent/3/forge-parent-3.pom (5 KB at 273.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.pom (8 KB at 375.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.pom (2 KB at 50.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.jar [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.jar (44 KB at 829.6 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar (7 KB at 141.5 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.jar (61 KB at 1281.9 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar (152 KB at 2570.8 KB/sec) [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/jenkins/workspace/workspace/catapult at 2/base/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ catapult-base --- [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.pom (7 KB at 134.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.pom (2 KB at 73.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.pom (3 KB at 19.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.pom (910 B at 0.9 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/1.1.18/plexus-components-1.1.18.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/1.1.18/plexus-components-1.1.18.pom (6 KB at 35.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.pom (2 KB at 15.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.pom (3 KB at 27.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.pom (3 KB at 50.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.pom (2 KB at 32.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom (8 KB at 193.4 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.pom (3 KB at 43.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.pom (4 KB at 100.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.pom (2 KB at 85.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.pom (4 KB at 93.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.pom (5 KB at 92.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.pom [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.pom (4 KB at 179.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.pom (891 B at 45.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler/2.7/plexus-compiler-2.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler/2.7/plexus-compiler-2.7.pom (5 KB at 172.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/4.0/plexus-components-4.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/4.0/plexus-components-4.0.pom (3 KB at 41.2 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom (21 KB at 488.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.pom (711 B at 18.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.pom (792 B at 29.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compilers/2.7/plexus-compilers-2.7.pom [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compilers/2.7/plexus-compilers-2.7.pom (2 KB at 54.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.jar [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.jar [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.jar [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.jar [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.jar (37 KB at 604.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.jar (30 KB at 466.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.jar (46 KB at 651.0 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.jar (145 KB at 2125.1 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.jar (515 KB at 4901.8 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.jar (14 KB at 110.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.jar (104 KB at 804.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar (50 KB at 370.3 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.jar (73 KB at 404.7 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar (60 KB at 329.5 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar (106 KB at 483.6 KB/sec) [INFO] Downloading: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.jar [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.jar (37 KB at 156.3 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.jar (26 KB at 104.6 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.jar (5 KB at 18.1 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar (14 KB at 51.8 KB/sec) [INFO] Downloaded: http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.jar (20 KB at 72.9 KB/sec) [INFO] Changes detected - recompiling the module! [INFO] Compiling 1 source file to /home/jenkins/workspace/workspace/catapult at 2/base/target/classes # [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/jenkins/workspace/workspace/catapult at 2/base/src/main/java/org/kontinuity/catapult/base/EnvironmentSupport.java:[30,59] non-static variable MESSAGE_PATTERN cannot be referenced from a static context [INFO] 1 error [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] catapult-parent .................................... SUCCESS [ 38.535 s] [INFO] catapult-base ...................................... FAILURE [ 8.106 s] [INFO] catapult-service-github-api ........................ SKIPPED [INFO] catapult-service-openshift-api ..................... SKIPPED [INFO] catapult-core-api .................................. SKIPPED [INFO] catapult-service-github-impl ....................... SKIPPED [INFO] catapult-service-openshift-impl .................... SKIPPED [INFO] catapult-core-impl ................................. SKIPPED [INFO] catapult-web ....................................... SKIPPED [INFO] catapult-tests ..................................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 54.329 s [INFO] Finished at: 2016-05-01T06:02:58+00:00 [INFO] Final Memory: 26M/203M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project catapult-base: Compilation failure [ERROR] /home/jenkins/workspace/workspace/catapult at 2/base/src/main/java/org/kontinuity/catapult/base/EnvironmentSupport.java:[30,59] non-static variable MESSAGE_PATTERN cannot be referenced from a static context [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :catapult-base [Pipeline] step From alr at redhat.com Sun May 1 06:20:33 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Sun, 1 May 2016 11:50:33 +0530 Subject: [kontinuity-dev-public] Build failed in Jenkins: catapult #13 In-Reply-To: <1223294909.9.1462082581741.JavaMail.root@jenkins-c7fj5> References: <1223294909.9.1462082581741.JavaMail.root@jenkins-c7fj5> Message-ID: 1) Glad to see our alert system is working 2) Yes, that was me who broke the build. Me. #Shame. S, ALR On Sun, May 1, 2016 at 11:33 AM, wrote: > See > > ------------------------------------------ > [...truncated 1035 lines...] > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/aether/aether-spi/1.0.0.v20140518/aether-spi-1.0.0.v20140518.jar > (31 KB at 92.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/eclipse/aether/aether-transport-wagon/1.0.0.v20140518/aether-transport-wagon-1.0.0.v20140518.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/aether/aether-api/1.0.0.v20140518/aether-api-1.0.0.v20140518.jar > (134 KB at 364.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.2.5/maven-aether-provider-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/aether/aether-transport-wagon/1.0.0.v20140518/aether-transport-wagon-1.0.0.v20140518.jar > (25 KB at 62.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-model/3.2.5/maven-model-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/aether/aether-connector-basic/1.0.0.v20140518/aether-connector-basic-1.0.0.v20140518.jar > (36 KB at 76.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.2.5/maven-model-builder-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar > (143 KB at 297.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.2.5/maven-repository-metadata-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-model/3.2.5/maven-model-3.2.5.jar > (158 KB at 305.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.2.5/maven-settings-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.2.5/maven-aether-provider-3.2.5.jar > (65 KB at 124.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.2.5/maven-settings-builder-3.2.5.jar > [INFO] Downloaded: > http://nexus/content/groups/public/javax/javaee-api/7.0/javaee-api-7.0.jar > (1886 KB at 3453.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/com/google/guava/guava/18.0/guava-18.0.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.2.5/maven-model-builder-3.2.5.jar > (167 KB at 302.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.2.5/maven-repository-metadata-3.2.5.jar > (26 KB at 45.4 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.2.5/maven-settings-builder-3.2.5.jar > (43 KB at 76.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-provider-api/2.6/wagon-provider-api-2.6.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.2.5/maven-settings-3.2.5.jar > (43 KB at 72.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-file/2.6/wagon-file-2.6.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-file/2.6/wagon-file-2.6.jar > (12 KB at 17.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-lightweight/2.6/wagon-http-lightweight-2.6.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar > (238 KB at 365.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-shared/2.6/wagon-http-shared-2.6.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-provider-api/2.6/wagon-provider-api-2.6.jar > (52 KB at 70.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jsoup/jsoup/1.7.2/jsoup-1.7.2.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar > (61 KB at 66.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-impl-maven-archive/2.2.1/shrinkwrap-resolver-impl-maven-archive-2.2.1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-lightweight/2.6/wagon-http-lightweight-2.6.jar > (16 KB at 16.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-spi-maven-archive/2.2.1/shrinkwrap-resolver-spi-maven-archive-2.2.1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/wagon/wagon-http-shared/2.6/wagon-http-shared-2.6.jar > (11 KB at 10.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.0.M1/org.eclipse.sisu.plexus-0.3.0.M1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jsoup/jsoup/1.7.2/jsoup-1.7.2.jar > (287 KB at 294.4 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar > [INFO] Downloaded: > http://nexus/content/groups/public/com/google/guava/guava/18.0/guava-18.0.jar > (2204 KB at 2218.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar > [INFO] Downloaded: > http://nexus/content/groups/public/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar > (44 KB at 38.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/javax/inject/javax.inject/1/javax.inject-1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.0.M1/org.eclipse.sisu.plexus-0.3.0.M1.jar > (196 KB at 172.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.0.M1/org.eclipse.sisu.inject-0.3.0.M1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-spi-maven-archive/2.2.1/shrinkwrap-resolver-spi-maven-archive-2.2.1.jar > (6 KB at 5.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.3/plexus-compiler-javac-2.3.jar > [INFO] Downloaded: > http://nexus/content/groups/public/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar > (6 KB at 4.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.3/plexus-compiler-api-2.3.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-impl-maven-archive/2.2.1/shrinkwrap-resolver-impl-maven-archive-2.2.1.jar > (50 KB at 40.4 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-container/1.1.11.Final/arquillian-junit-container-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/javax/inject/javax.inject/1/javax.inject-1.jar > (3 KB at 1.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-core/1.1.11.Final/arquillian-junit-core-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.0.M1/org.eclipse.sisu.inject-0.3.0.M1.jar > (333 KB at 204.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-api/1.1.11.Final/arquillian-test-api-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.3/plexus-compiler-javac-2.3.jar > (19 KB at 11.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-api/1.1.11.Final/arquillian-core-api-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.3/plexus-compiler-api-2.3.jar > (25 KB at 15.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-spi/1.1.11.Final/arquillian-test-spi-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-container/1.1.11.Final/arquillian-junit-container-1.1.11.Final.jar > (9 KB at 4.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-spi/1.1.11.Final/arquillian-core-spi-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/junit/arquillian-junit-core/1.1.11.Final/arquillian-junit-core-1.1.11.Final.jar > (38 KB at 21.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-api/1.1.11.Final/arquillian-container-test-api-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-spi/1.1.11.Final/arquillian-test-spi-1.1.11.Final.jar > (41 KB at 21.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-spi/1.1.11.Final/arquillian-container-test-spi-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-api/1.1.11.Final/arquillian-core-api-1.1.11.Final.jar > (10 KB at 4.9 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-api/1.1.11.Final/arquillian-test-api-1.1.11.Final.jar > (4 KB at 1.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0-alpha-8/shrinkwrap-descriptors-api-base-2.0.0-alpha-8.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-spi/1.1.11.Final/arquillian-container-spi-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-spi/1.1.11.Final/arquillian-core-spi-1.1.11.Final.jar > (27 KB at 13.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-impl-base/1.1.11.Final/arquillian-core-impl-base-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-api/1.1.11.Final/arquillian-container-test-api-1.1.11.Final.jar > (9 KB at 4.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-impl-base/1.1.11.Final/arquillian-test-impl-base-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0-alpha-8/shrinkwrap-descriptors-api-base-2.0.0-alpha-8.jar > (17 KB at 8.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-impl-base/1.1.11.Final/arquillian-container-impl-base-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-spi/1.1.11.Final/arquillian-container-spi-1.1.11.Final.jar > (51 KB at 24.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-api/1.1.11.Final/arquillian-config-api-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-spi/1.1.11.Final/arquillian-container-test-spi-1.1.11.Final.jar > (26 KB at 11.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-impl-base/1.1.11.Final/arquillian-config-impl-base-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/test/arquillian-test-impl-base/1.1.11.Final/arquillian-test-impl-base-1.1.11.Final.jar > (28 KB at 12.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0-alpha-8/shrinkwrap-descriptors-spi-2.0.0-alpha-8.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/core/arquillian-core-impl-base/1.1.11.Final/arquillian-core-impl-base-1.1.11.Final.jar > (61 KB at 27.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-impl-base/1.1.11.Final/arquillian-container-test-impl-base-1.1.11.Final.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-impl-base/1.1.11.Final/arquillian-container-impl-base-1.1.11.Final.jar > (78 KB at 35.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.3/shrinkwrap-impl-base-1.2.3.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-api/1.1.11.Final/arquillian-config-api-1.1.11.Final.jar > (8 KB at 3.3 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/config/arquillian-config-impl-base/1.1.11.Final/arquillian-config-impl-base-1.1.11.Final.jar > (41 KB at 18.1 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0-alpha-8/shrinkwrap-descriptors-spi-2.0.0-alpha-8.jar > (38 KB at 16.7 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/arquillian/container/arquillian-container-test-impl-base/1.1.11.Final/arquillian-container-test-impl-base-1.1.11.Final.jar > (107 KB at 47.6 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.3/shrinkwrap-impl-base-1.2.3.jar > (187 KB at 83.2 KB/sec) > [INFO] > [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ catapult-base > --- > [INFO] Deleting /home/jenkins/workspace/workspace/catapult at 2/base/target > [INFO] > [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-java-version) @ > catapult-base --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @ > catapult-base --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.4:create (get-scm-revision) @ > catapult-base --- > [INFO] > [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ > catapult-base --- > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.pom > (7 KB at 138.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.pom > (4 KB at 104.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom > (5 KB at 94.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.12/plexus-interpolation-1.12.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.12/plexus-interpolation-1.12.pom > (889 B at 21.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.pom > (3 KB at 93.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/spice/spice-parent/10/spice-parent-10.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/spice/spice-parent/10/spice-parent-10.pom > (3 KB at 73.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/forge/forge-parent/3/forge-parent-3.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/forge/forge-parent/3/forge-parent-3.pom > (5 KB at 273.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-utils/1.5.8/plexus-utils-1.5.8.pom > (8 KB at 375.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.pom > (2 KB at 50.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-filtering/1.2/maven-filtering-1.2.jar > (44 KB at 829.6 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > (7 KB at 141.5 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.19/plexus-interpolation-1.19.jar > (61 KB at 1281.9 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar > (152 KB at 2570.8 KB/sec) > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /home/jenkins/workspace/workspace/catapult at 2/base/src/main/resources > [INFO] > [INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ > catapult-base --- > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.pom > (7 KB at 134.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.pom > (2 KB at 73.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.pom > (3 KB at 19.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.pom > (910 B at 0.9 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/1.1.18/plexus-components-1.1.18.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/1.1.18/plexus-components-1.1.18.pom > (6 KB at 35.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.pom > (2 KB at 15.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.pom > (3 KB at 27.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.pom > (3 KB at 50.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.pom > (2 KB at 32.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom > (8 KB at 193.4 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.pom > (3 KB at 43.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.pom > (4 KB at 100.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.pom > (2 KB at 85.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.pom > (4 KB at 93.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.pom > (5 KB at 92.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-utils/0.1/maven-shared-utils-0.1.pom > (4 KB at 179.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.pom > (891 B at 45.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler/2.7/plexus-compiler-2.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler/2.7/plexus-compiler-2.7.pom > (5 KB at 172.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/4.0/plexus-components-4.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-components/4.0/plexus-components-4.0.pom > (3 KB at 41.2 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom > (21 KB at 488.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.pom > (711 B at 18.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.pom > (792 B at 29.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compilers/2.7/plexus-compilers-2.7.pom > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compilers/2.7/plexus-compilers-2.7.pom > (2 KB at 54.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.jar > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.jar > (37 KB at 604.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.jar > (30 KB at 466.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-settings/3.0/maven-settings-3.0.jar > (46 KB at 651.0 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.jar > (145 KB at 2125.1 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-core/3.0/maven-core-3.0.jar > (515 KB at 4901.8 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.jar > (14 KB at 110.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.jar > (104 KB at 804.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar > (50 KB at 370.3 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-api/1.7/aether-api-1.7.jar > (73 KB at 404.7 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar > (60 KB at 329.5 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar > (106 KB at 483.6 KB/sec) > [INFO] Downloading: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.jar > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/maven-toolchain/2.2.1/maven-toolchain-2.2.1.jar > (37 KB at 156.3 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-api/2.7/plexus-compiler-api-2.7.jar > (26 KB at 104.6 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-manager/2.7/plexus-compiler-manager-2.7.jar > (5 KB at 18.1 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar > (14 KB at 51.8 KB/sec) > [INFO] Downloaded: > http://nexus/content/groups/public/org/codehaus/plexus/plexus-compiler-javac/2.7/plexus-compiler-javac-2.7.jar > (20 KB at 72.9 KB/sec) > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 1 source file to > /home/jenkins/workspace/workspace/catapult at 2/base/target/classes > # [INFO] ------------------------------------------------------------- > [ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] /home/jenkins/workspace/workspace/catapult at 2/base/src/main/java/org/kontinuity/catapult/base/EnvironmentSupport.java:[30,59] > non-static variable MESSAGE_PATTERN cannot be referenced from a static > context > [INFO] 1 error > [INFO] ------------------------------------------------------------- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] catapult-parent .................................... SUCCESS [ > 38.535 s] > [INFO] catapult-base ...................................... FAILURE [ > 8.106 s] > [INFO] catapult-service-github-api ........................ SKIPPED > [INFO] catapult-service-openshift-api ..................... SKIPPED > [INFO] catapult-core-api .................................. SKIPPED > [INFO] catapult-service-github-impl ....................... SKIPPED > [INFO] catapult-service-openshift-impl .................... SKIPPED > [INFO] catapult-core-impl ................................. SKIPPED > [INFO] catapult-web ....................................... SKIPPED > [INFO] catapult-tests ..................................... SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 54.329 s > [INFO] Finished at: 2016-05-01T06:02:58+00:00 > [INFO] Final Memory: 26M/203M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile > (default-compile) on project catapult-base: Compilation failure > [ERROR] /home/jenkins/workspace/workspace/catapult at 2/base/src/main/java/org/kontinuity/catapult/base/EnvironmentSupport.java:[30,59] > non-static variable MESSAGE_PATTERN cannot be referenced from a static > context > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :catapult-base > [Pipeline] step > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Mon May 2 05:22:04 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Mon, 2 May 2016 10:52:04 +0530 Subject: [kontinuity-dev-public] Show Redirect on OpenShift Console Login Page Message-ID: The final stage of Catapult after setting up a project on behalf of the user is redirecting them to the Project Overview page; a simple HTTP 303, really. So say I execute that redirect to: https://10.10.9.28:8443/console/project/alr-test/overview I'm presented with the login page (which, hey, makes sense). The login process catches my initial request and notes to forward me along after I've authenticated: https://10.10.9.28:8443/login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-console%26response_type%3Dtoken%26state%3D%252Fproject%252Falr-test%252Foverview%26redirect_uri%3Dhttps%253A%252F%252F10.10.9.28%253A8443%252Fconsole%252Foauth But the user's got no visual indication on the login page that this is what's going to happen. Can we open an issue to put something on the screen that says something like: "Hey-o! We'd love to take you to /project/alr-test/overview; just log in below and we'll have you on your way." So which ML or issue tracker should I make this request to the console team? OR even better if I can on the backend get some one-time token for the user I can pass in which auto-logs them in, that'd be even better. S, ALR -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffranz at redhat.com Mon May 2 14:33:17 2016 From: ffranz at redhat.com (Fabiano Franz) Date: Mon, 2 May 2016 11:33:17 -0300 Subject: [kontinuity-dev-public] Show Redirect on OpenShift Console Login Page In-Reply-To: References: Message-ID: Hey Andrew, We use Trello and the board for the UI team is here: https://trello.com/b/nbkIrqKa/user-interface Just add something in "New". Copying Jessica and Sam to make sure they are following this. Thanks! Fabiano Franz On Mon, May 2, 2016 at 2:22 AM, Andrew Lee Rubinger wrote: > The final stage of Catapult after setting up a project on behalf of the > user is redirecting them to the Project Overview page; a simple HTTP 303, > really. > > So say I execute that redirect to: > > https://10.10.9.28:8443/console/project/alr-test/overview > > I'm presented with the login page (which, hey, makes sense). The login > process catches my initial request and notes to forward me along after I've > authenticated: > > > https://10.10.9.28:8443/login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-console%26response_type%3Dtoken%26state%3D%252Fproject%252Falr-test%252Foverview%26redirect_uri%3Dhttps%253A%252F%252F10.10.9.28%253A8443%252Fconsole%252Foauth > > But the user's got no visual indication on the login page that this is > what's going to happen. Can we open an issue to put something on the > screen that says something like: > > "Hey-o! We'd love to take you to /project/alr-test/overview; just log > in below and we'll have you on your way." > > So which ML or issue tracker should I make this request to the console > team? OR even better if I can on the backend get some one-time token for > the user I can pass in which auto-logs them in, that'd be even better. > > S, > ALR > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jforrest at redhat.com Mon May 2 14:36:30 2016 From: jforrest at redhat.com (Jessica Forrester) Date: Mon, 2 May 2016 10:36:30 -0400 Subject: [kontinuity-dev-public] Show Redirect on OpenShift Console Login Page In-Reply-To: References: Message-ID: Anything auth related involves the platform mgmt team. CC'ing Jordan On Mon, May 2, 2016 at 10:33 AM, Fabiano Franz wrote: > Hey Andrew, > > We use Trello and the board for the UI team is here: > > https://trello.com/b/nbkIrqKa/user-interface > > Just add something in "New". Copying Jessica and Sam to make sure they are > following this. > > Thanks! > > Fabiano Franz > > > On Mon, May 2, 2016 at 2:22 AM, Andrew Lee Rubinger > wrote: > >> The final stage of Catapult after setting up a project on behalf of the >> user is redirecting them to the Project Overview page; a simple HTTP 303, >> really. >> >> So say I execute that redirect to: >> >> https://10.10.9.28:8443/console/project/alr-test/overview >> >> I'm presented with the login page (which, hey, makes sense). The login >> process catches my initial request and notes to forward me along after I've >> authenticated: >> >> >> https://10.10.9.28:8443/login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-console%26response_type%3Dtoken%26state%3D%252Fproject%252Falr-test%252Foverview%26redirect_uri%3Dhttps%253A%252F%252F10.10.9.28%253A8443%252Fconsole%252Foauth >> >> But the user's got no visual indication on the login page that this is >> what's going to happen. Can we open an issue to put something on the >> screen that says something like: >> >> "Hey-o! We'd love to take you to /project/alr-test/overview; just log >> in below and we'll have you on your way." >> >> So which ML or issue tracker should I make this request to the console >> team? OR even better if I can on the backend get some one-time token for >> the user I can pass in which auto-logs them in, that'd be even better. >> >> S, >> ALR >> >> -- >> Red Hat Developer Programs Architecture >> @ALRubinger >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jliggitt at redhat.com Mon May 2 14:40:32 2016 From: jliggitt at redhat.com (Jordan Liggitt) Date: Mon, 2 May 2016 10:40:32 -0400 Subject: [kontinuity-dev-public] Show Redirect on OpenShift Console Login Page In-Reply-To: References: Message-ID: The final destination is three layers deep at that point: 1. successful login returns to the "then" param, which puts them back in the OAuth flow (/oauth/authorize) 2. successful token grant returns to the "redirect_uri" param, which sends them back to the console (/console/oauth) 3. once the console gets the API token, it pulls the original page out of the returned state param and directs the user there The redirect_uri and state param are opaque to the login page. I don't think there's a reasonable way to extract information from them for the login page to display without coupling the login page (which is API-wide) to the console (which could be just one of the OAuth clients). On Mon, May 2, 2016 at 10:36 AM, Jessica Forrester wrote: > Anything auth related involves the platform mgmt team. CC'ing Jordan > > On Mon, May 2, 2016 at 10:33 AM, Fabiano Franz wrote: > >> Hey Andrew, >> >> We use Trello and the board for the UI team is here: >> >> https://trello.com/b/nbkIrqKa/user-interface >> >> Just add something in "New". Copying Jessica and Sam to make sure they >> are following this. >> >> Thanks! >> >> Fabiano Franz >> >> >> On Mon, May 2, 2016 at 2:22 AM, Andrew Lee Rubinger >> wrote: >> >>> The final stage of Catapult after setting up a project on behalf of the >>> user is redirecting them to the Project Overview page; a simple HTTP 303, >>> really. >>> >>> So say I execute that redirect to: >>> >>> https://10.10.9.28:8443/console/project/alr-test/overview >>> >>> I'm presented with the login page (which, hey, makes sense). The login >>> process catches my initial request and notes to forward me along after I've >>> authenticated: >>> >>> >>> https://10.10.9.28:8443/login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-console%26response_type%3Dtoken%26state%3D%252Fproject%252Falr-test%252Foverview%26redirect_uri%3Dhttps%253A%252F%252F10.10.9.28%253A8443%252Fconsole%252Foauth >>> >>> But the user's got no visual indication on the login page that this is >>> what's going to happen. Can we open an issue to put something on the >>> screen that says something like: >>> >>> "Hey-o! We'd love to take you to /project/alr-test/overview; just log >>> in below and we'll have you on your way." >>> >>> So which ML or issue tracker should I make this request to the console >>> team? OR even better if I can on the backend get some one-time token for >>> the user I can pass in which auto-logs them in, that'd be even better. >>> >>> S, >>> ALR >>> >>> -- >>> Red Hat Developer Programs Architecture >>> @ALRubinger >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnozicka at redhat.com Mon May 2 18:09:38 2016 From: tnozicka at redhat.com (Tomas Nozicka) Date: Mon, 02 May 2016 20:09:38 +0200 Subject: [kontinuity-dev-public] Type of Jenkins setup for summit Message-ID: <1462212578.15706.83.camel@redhat.com> I have started to write Jenkinsfile for helloworld project [1] and soon found out that they will be completely dependent on how we will run Jenkins pipelines on OpenShift for summit (or in general). Here is a few relevant ways I could think of: 1) Kubernetes/OpenShift-plugin - on-demand slaves with 1-N Kubernetes/Openshift clusters with corresponding build images = example = node('docker-centos-7-java') { ? stage 'Build'? ? bash 'mvn package && docker build .' } 2) Master with/without slaves running sub-job builds on Kubernetes/Openshift cluster = example = node { ? kubernetes.pod('buildpod').withImage('docker-centos-7-java').inside{ ? bash 'mvn package && docker build .' } } 3) Master with/without slaves running running simple jobs and only calling OpenShift API to do the work = example = node { ? // oc.createNamespace(dev) ? // oc.setupS2I(buildConfig) ? // oc.startBuild() ? input "Is http://dev.openshift.rh.com/ OK? ? // oc deploy it to production namespace } Which approach are we going to use? Also since we are targeting multiple languages (at least OpenShift does) there is a question of the build images. This is mostly for option 1 and 2 because in option 3 user can easily switch them for their own. With option 1 and 2 adding another build image requires to be Jenkins administrator to setup a new docker cloud pool with the image and label (AFAIK). The only generic way is to use image like 'centos-7' and have your pipelines install dependencies on their own: node('docker-centos-7') { ? stage 'Build' ? bash 'yum install -y maven docker ?# and other stuff'? ? bash 'mvn package && docker build .' } Also in case of option 1 and 2 if we setup the on-demand slave provisioning to last only for one job we will always have clean image and dependencies and we can install whatever we want there. Option 3 is one shot by default. I like option 2 or 3 depending on if we use S2I or docker build.? (I am going to open a debate on S2I vs. docker build in a separate thread.) Regards, Tomas [1] -?https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0 .x-develop/helloworld From tnozicka at redhat.com Mon May 2 18:39:19 2016 From: tnozicka at redhat.com (Tomas Nozicka) Date: Mon, 02 May 2016 20:39:19 +0200 Subject: [kontinuity-dev-public] S2I vs. docker build Message-ID: <1462214359.15706.103.camel@redhat.com> As I have written in a previous post I started to write Jenkinsfiles for the helloworld application and I am not sure how will we build docker images. The are 2 ways: 1) [Classic] Build it in your Jenkins job/build and call 'docker build' ?- 'docker build' needs to be root/privileged and will not be allowed to run on OpenShift Online (AFAIK) ?- can be setup to do a 2-phase build for compiled languages 2) S2I (OpenShift concept [1]) ?- runs S2I image as non root and commits and tags the resulting image at the end ?- works on OpenShift Online ?- harder to setup and work with ?- does not do a 2-phase build /yet/ for compiled languages as some people think (including myself until today) What type of build are we going to use? Are we targeting OpenShift Online? Thanks, Tomas [1] -?https://docs.openshift.org/latest/architecture/core_concepts/buil ds_and_image_streams.html#source-build S2I for Java -?https://docs.openshift.org/latest/using_images/s2i_image s/java.html From rmartine at redhat.com Mon May 2 18:44:18 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Mon, 2 May 2016 15:44:18 -0300 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <1462214359.15706.103.camel@redhat.com> References: <1462214359.15706.103.camel@redhat.com> Message-ID: On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka wrote: > As I have written in a previous post I started to write Jenkinsfiles > for the helloworld application and I am not sure how will we build > docker images. The are 2 ways: > > 1) [Classic] Build it in your Jenkins job/build and call 'docker build' > - 'docker build' needs to be root/privileged and will not be allowed > to run on OpenShift Online (AFAIK) > - can be setup to do a 2-phase build for compiled languages > > 2) S2I (OpenShift concept [1]) > - runs S2I image as non root and commits and tags the resulting image > at the end > - works on OpenShift Online > - harder to setup and work with > - does not do a 2-phase build /yet/ for compiled languages as some > people think (including myself until today) > > What type of build are we going to use? > If no one decided yet I'd prefer Source-to-Image since it is more aligned with how OpenShift builds application inside docker containers easily. Also, based on all our examples inside Red Hat Developers, we have only code. No Dockerfiles. One more reason to use S2I. > > Are we targeting OpenShift Online? > AFAIK, we are targetting whatever the user is running Openshift (either locally or remote, no matter if it is Enterprise, Dedicated or Online). > > Thanks, > Tomas > > [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil > ds_and_image_streams.html#source-build > S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image > s/java.html > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 00:48:56 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 06:18:56 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira < rmartine at redhat.com> wrote: > > > On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka wrote: > >> As I have written in a previous post I started to write Jenkinsfiles >> for the helloworld application and I am not sure how will we build >> docker images. The are 2 ways: >> >> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >> - 'docker build' needs to be root/privileged and will not be allowed >> to run on OpenShift Online (AFAIK) >> - can be setup to do a 2-phase build for compiled languages >> >> 2) S2I (OpenShift concept [1]) >> - runs S2I image as non root and commits and tags the resulting image >> at the end >> - works on OpenShift Online >> - harder to setup and work with >> - does not do a 2-phase build /yet/ for compiled languages as some >> people think (including myself until today) >> >> What type of build are we going to use? >> > > If no one decided yet I'd prefer Source-to-Image since it is more aligned > with how OpenShift builds application inside docker containers easily. > Also, based on all our examples inside Red Hat Developers, we have only > code. No Dockerfiles. One more reason to use S2I. > Right, it was my understanding we'd delegate the building of the images to OpenShift (kind of one of the main selling points for OS over stock K8s), which in turn is implemented using s2i. This alleviates the responsibility of the developer to know anything about image construction; they focus on their app and choose the deployment target like "EAP" or "Node" and we abstract away the containerization parts. > > >> Are we targeting OpenShift Online? >> > > AFAIK, we are targetting whatever the user is running Openshift (either > locally or remote, no matter if it is Enterprise, Dedicated or Online). > +1. > > >> >> Thanks, >> Tomas >> >> [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil >> ds_and_image_streams.html#source-build >> >> S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image >> s/java.html >> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Tue May 3 00:55:49 2016 From: bparees at redhat.com (Ben Parees) Date: Mon, 2 May 2016 20:55:49 -0400 Subject: [kontinuity-dev-public] Type of Jenkins setup for summit In-Reply-To: <1462212578.15706.83.camel@redhat.com> References: <1462212578.15706.83.camel@redhat.com> Message-ID: I would expect some combination of option 2 and option 3.. that is, some part of the pipeline should include running an s2i build on openshift, and some other part should include launching a temporary jenkins slave pod in the cluster. That demonstrates the flexibility of the system and the power of temporary slaves. On Mon, May 2, 2016 at 2:09 PM, Tomas Nozicka wrote: > I have started to write Jenkinsfile for helloworld project [1] and soon > found out that they will be completely dependent on how we will run > Jenkins pipelines on OpenShift for summit (or in general). Here is a > few relevant ways I could think of: > > 1) Kubernetes/OpenShift-plugin - on-demand slaves with 1-N > Kubernetes/Openshift clusters with corresponding build images > = example = > node('docker-centos-7-java') { > stage 'Build' > bash 'mvn package && docker build .' > } > > 2) Master with/without slaves running sub-job builds on > Kubernetes/Openshift cluster > = example = > node { > kubernetes.pod('buildpod').withImage('docker-centos-7-java').inside{ > bash 'mvn package && docker build .' } > } > > 3) Master with/without slaves running running simple jobs and only > calling OpenShift API to do the work > = example = > node { > // oc.createNamespace(dev) > // oc.setupS2I(buildConfig) > // oc.startBuild() > input "Is http://dev.openshift.rh.com/ OK? > // oc deploy it to production namespace > } > > Which approach are we going to use? > > Also since we are targeting multiple languages (at least OpenShift > does) there is a question of the build images. This is mostly for > option 1 and 2 because in option 3 user can easily switch them for > their own. With option 1 and 2 adding another build image requires to > be Jenkins administrator to setup a new docker cloud pool with the > image and label (AFAIK). The only generic way is to use image like > 'centos-7' and have your pipelines install dependencies on their own: > node('docker-centos-7') { > stage 'Build' > bash 'yum install -y maven > docker # and other stuff' > bash 'mvn package && docker build .' > } > > Also in case of option 1 and 2 if we setup the on-demand slave > provisioning to last only for one job we will always have clean image > and dependencies and we can install whatever we want there. Option 3 is > one shot by default. > > I like option 2 or 3 depending on if we use S2I or docker build. > (I am going to open a debate on S2I vs. docker build in a separate > thread.) > > > Regards, > Tomas > > [1] - https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0 > .x-develop/helloworld > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Tue May 3 01:00:03 2016 From: bparees at redhat.com (Ben Parees) Date: Mon, 2 May 2016 21:00:03 -0400 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <1462214359.15706.103.camel@redhat.com> References: <1462214359.15706.103.camel@redhat.com> Message-ID: On Mon, May 2, 2016 at 2:39 PM, Tomas Nozicka wrote: > As I have written in a previous post I started to write Jenkinsfiles > for the helloworld application and I am not sure how will we build > docker images. The are 2 ways: > > 1) [Classic] Build it in your Jenkins job/build and call 'docker build' > - 'docker build' needs to be root/privileged and will not be allowed > to run on OpenShift Online (AFAIK) > - can be setup to do a 2-phase build for compiled languages > > 2) S2I (OpenShift concept [1]) > - runs S2I image as non root and commits and tags the resulting image > at the end > - works on OpenShift Online > - harder to setup and work with > - does not do a 2-phase build /yet/ for compiled languages as some > people think (including myself until today) > I ?agree ?with what others have said in this thread, but just wanted to note that while there is no first class support for a 2-phase build, there are two other approaches available: 1) use an image that has both the build tools and runtime tools in the same image. For example, our EAP, JWS, and Wildfly images all do this, so you can use them with s2i just fine, as long as you don't mind that your final application image will include maven/jdk(not just a jre). 2) define two builds, first build uses a maven image to build war, results in an image containing a war file. second build takes the output image from the first build as its input, extracts the war and lays it on top of a runtime-only image. More details on how the "input from an image" is defined here: https://docs.openshift.org/latest/dev_guide/builds.html#image-source We are also this sprint starting work on the first class implementation of two phase builds (what we call extended builds..where you have 2 images, one that's the builder image and one that's the runtime image). It won't be done this sprint, but it is a target for 3.3. > > What type of build are we going to use? > > Are we targeting OpenShift Online? > > Thanks, > Tomas > > [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil > ds_and_image_streams.html#source-build > S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image > s/java.html > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartine at redhat.com Tue May 3 03:00:08 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Tue, 3 May 2016 00:00:08 -0300 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: I've never heard about this approach, and thinking about the docker image size it could be a good approach when build pipeline is promoting a build from QA to Production. From Jenkins perspective, can this be done(promote binary from QA to Production using this strategy)? On Mon, May 2, 2016 at 10:00 PM, Ben Parees wrote: > > > On Mon, May 2, 2016 at 2:39 PM, Tomas Nozicka wrote: > >> As I have written in a previous post I started to write Jenkinsfiles >> for the helloworld application and I am not sure how will we build >> docker images. The are 2 ways: >> >> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >> - 'docker build' needs to be root/privileged and will not be allowed >> to run on OpenShift Online (AFAIK) >> - can be setup to do a 2-phase build for compiled languages >> >> 2) S2I (OpenShift concept [1]) >> - runs S2I image as non root and commits and tags the resulting image >> at the end >> - works on OpenShift Online >> - harder to setup and work with >> - does not do a 2-phase build /yet/ for compiled languages as some >> people think (including myself until today) >> > > I ?agree ?with what others have said in this thread, but just wanted to > note that while there is no first class support for a 2-phase build, there > are two other approaches available: > > 1) use an image that has both the build tools and runtime tools in the > same image. For example, our EAP, JWS, and Wildfly images all do this, so > you can use them with s2i just fine, as long as you don't mind that your > final application image will include maven/jdk(not just a jre). > > 2) define two builds, first build uses a maven image to build war, results > in an image containing a war file. second build takes the output image > from the first build as its input, extracts the war and lays it on top of a > runtime-only image. More details on how the "input from an image" is > defined here: > https://docs.openshift.org/latest/dev_guide/builds.html#image-source > > We are also this sprint starting work on the first class implementation of > two phase builds (what we call extended builds..where you have 2 images, > one that's the builder image and one that's the runtime image). It won't > be done this sprint, but it is a target for 3.3. > > > > >> >> What type of build are we going to use? >> >> Are we targeting OpenShift Online? >> >> Thanks, >> Tomas >> >> [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil >> ds_and_image_streams.html#source-build >> >> S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image >> s/java.html >> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> > > > > -- > Ben Parees | OpenShift > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ablock at redhat.com Tue May 3 03:07:21 2016 From: ablock at redhat.com (Andrew Block) Date: Mon, 2 May 2016 23:07:21 -0400 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: The two phase build is a very intriguing feature. I have had many customers question why we are packaging build tools as part of our production image. This would certainly give them the flexibility to take advantage of the source to image feature of OpenShift, but to utilize a lean image for their production deployment. I look forward to seeing how this approach matures and to build collateral around it. - Andy ? Andrew Block Red Hat Consulting 101 N. Wacker, Suite 150 Chicago, IL 60606 andrew.block at redhat.com?| m. (716) 870-2408 On May 2, 2016 at 11:00:11 PM, Ricardo Martinelli de Oliveira (rmartine at redhat.com) wrote: I've never heard about this approach, and thinking about the docker image size it could be a good approach when build pipeline is promoting a build from QA to Production. From Jenkins perspective, can this be done(promote binary from QA to Production using this strategy)? On Mon, May 2, 2016 at 10:00 PM, Ben Parees wrote: On Mon, May 2, 2016 at 2:39 PM, Tomas Nozicka wrote: As I have written in a previous post I started to write Jenkinsfiles for the helloworld application and I am not sure how will we build docker images. The are 2 ways: 1) [Classic] Build it in your Jenkins job/build and call 'docker build' ?- 'docker build' needs to be root/privileged and will not be allowed to run on OpenShift Online (AFAIK) ?- can be setup to do a 2-phase build for compiled languages 2) S2I (OpenShift concept [1]) ?- runs S2I image as non root and commits and tags the resulting image at the end ?- works on OpenShift Online ?- harder to setup and work with ?- does not do a 2-phase build /yet/ for compiled languages as some people think (including myself until today) I ?agree ?with what others have said in this thread, but just wanted to note that while there is no first class support for a 2-phase build, there are two other approaches available: 1) use an image that has both the build tools and runtime tools in the same image.? For example, our EAP, JWS, and Wildfly images all do this, so you can use them with s2i just fine, as long as you don't mind that your final application image will include maven/jdk(not just a jre). 2) define two builds, first build uses a maven image to build war, results in an image containing a war file.? second build takes the output image from the first build as its input, extracts the war and lays it on top of a runtime-only image.? More details on how the "input from an image" is defined here: https://docs.openshift.org/latest/dev_guide/builds.html#image-source We are also this sprint starting work on the first class implementation of two phase builds (what we call extended builds..where you have 2 images, one that's the builder image and one that's the runtime image).? It won't be done this sprint, but it is a target for 3.3. ? What type of build are we going to use? Are we targeting OpenShift Online? Thanks, Tomas [1] -?https://docs.openshift.org/latest/architecture/core_concepts/buil ds_and_image_streams.html#source-build S2I for Java -?https://docs.openshift.org/latest/using_images/s2i_image s/java.html _______________________________________________ kontinuity-dev-public mailing list kontinuity-dev-public at redhat.com https://www.redhat.com/mailman/listinfo/kontinuity-dev-public -- Ben Parees | OpenShift _______________________________________________ kontinuity-dev-public mailing list kontinuity-dev-public at redhat.com https://www.redhat.com/mailman/listinfo/kontinuity-dev-public _______________________________________________ kontinuity-dev-public mailing list kontinuity-dev-public at redhat.com https://www.redhat.com/mailman/listinfo/kontinuity-dev-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Tue May 3 03:16:09 2016 From: bparees at redhat.com (Ben Parees) Date: Mon, 2 May 2016 23:16:09 -0400 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: On Mon, May 2, 2016 at 11:00 PM, Ricardo Martinelli de Oliveira < rmartine at redhat.com> wrote: > I've never heard about this approach, and thinking about the docker image > size it could be a good approach when build pipeline is promoting a build > from QA to Production. From Jenkins perspective, can this be done(promote > binary from QA to Production using this strategy)? > ?i understand your question, yes.... the way i'd expect this to work in a qa->production pipeline is: dev/test env does the maven build, produces image containing the war from the source dev/test env does the runtime build, produces the runtime image containing the war from the war in the image from the previous step dev/test tests the runtime image, tags/promotes that image to QA QA tests the runtime image, tags/promotes to prod. so only the "runtime" image would move through promotion. ? > > On Mon, May 2, 2016 at 10:00 PM, Ben Parees wrote: > >> >> >> On Mon, May 2, 2016 at 2:39 PM, Tomas Nozicka >> wrote: >> >>> As I have written in a previous post I started to write Jenkinsfiles >>> for the helloworld application and I am not sure how will we build >>> docker images. The are 2 ways: >>> >>> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >>> - 'docker build' needs to be root/privileged and will not be allowed >>> to run on OpenShift Online (AFAIK) >>> - can be setup to do a 2-phase build for compiled languages >>> >>> 2) S2I (OpenShift concept [1]) >>> - runs S2I image as non root and commits and tags the resulting image >>> at the end >>> - works on OpenShift Online >>> - harder to setup and work with >>> - does not do a 2-phase build /yet/ for compiled languages as some >>> people think (including myself until today) >>> >> >> I ?agree ?with what others have said in this thread, but just wanted to >> note that while there is no first class support for a 2-phase build, there >> are two other approaches available: >> >> 1) use an image that has both the build tools and runtime tools in the >> same image. For example, our EAP, JWS, and Wildfly images all do this, so >> you can use them with s2i just fine, as long as you don't mind that your >> final application image will include maven/jdk(not just a jre). >> >> 2) define two builds, first build uses a maven image to build war, >> results in an image containing a war file. second build takes the output >> image from the first build as its input, extracts the war and lays it on >> top of a runtime-only image. More details on how the "input from an image" >> is defined here: >> https://docs.openshift.org/latest/dev_guide/builds.html#image-source >> >> We are also this sprint starting work on the first class implementation >> of two phase builds (what we call extended builds..where you have 2 images, >> one that's the builder image and one that's the runtime image). It won't >> be done this sprint, but it is a target for 3.3. >> >> >> >> >>> >>> What type of build are we going to use? >>> >>> Are we targeting OpenShift Online? >>> >>> Thanks, >>> Tomas >>> >>> [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil >>> ds_and_image_streams.html#source-build >>> >>> S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image >>> s/java.html >>> >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >> >> >> >> -- >> Ben Parees | OpenShift >> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From ablock at redhat.com Tue May 3 03:36:51 2016 From: ablock at redhat.com (Andrew Block) Date: Mon, 2 May 2016 23:36:51 -0400 Subject: [kontinuity-dev-public] Distortion CI Design Documents Message-ID: Hello all, As many of you know, we are currently using a temporary CI environment for the distortion effort and more specifically to build and test Catapult at this point in time. We are in the process of designing a new environment that will be hosted in the CentOS CI environment that will replace the existing environment. Dharmit and I have started putting together several documents outlining the architecture and goals for the CI environment and would appreciate a review by the group as we continue to design the solution and will begin to stand up the environment in the coming days and weeks.? The following documents are ready for review: Diagram of the current CentOS environment and a V1 proposed architecture https://www.lucidchart.com/invitations/accept/17676de2-fdca-4e7c-b4e9-43373fda1fbe? Distortion CI Environment Design document https://docs.google.com/a/redhat.com/document/d/1Bms-hoWyL2OYvi3b_qwtjRAbgFWKS6gxQ5mxj-QEFIg/edit?usp=sharing? Please do not hesitate to reach out with any questions or concerns.? Thanks, Andy ? Andrew Block Red Hat Consulting 101 N. Wacker, Suite 150 Chicago, IL 60606 andrew.block at redhat.com?| m. (716) 870-2408 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 04:00:14 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 09:30:14 +0530 Subject: [kontinuity-dev-public] Distortion CI Design Documents In-Reply-To: References: Message-ID: Awesome. I've added a section at the top to capture the test requirements (as discussed and adjusted in the thread "Test Stages of Kontinuity Catapult" from the RHT-internal "distortion" list (before we had a public place for these discussions). And I believe my other input is in the GDoc in the form of Google Comments. S, ALR On Tue, May 3, 2016 at 9:06 AM, Andrew Block wrote: > Hello all, > > As many of you know, we are currently using a temporary CI environment for > the distortion effort and more specifically to build and test Catapult at > this point in time. We are in the process of designing a new environment > that will be hosted in the CentOS CI environment that will replace the > existing environment. > > Dharmit and I have started putting together several documents outlining > the architecture and goals for the CI environment and would appreciate a > review by the group as we continue to design the solution and will begin to > stand up the environment in the coming days and weeks. > > The following documents are ready for review: > > - Diagram of the current CentOS environment and a V1 proposed > architecture > - > https://www.lucidchart.com/invitations/accept/17676de2-fdca-4e7c-b4e9-43373fda1fbe > > - Distortion CI Environment Design document > - > https://docs.google.com/a/redhat.com/document/d/1Bms-hoWyL2OYvi3b_qwtjRAbgFWKS6gxQ5mxj-QEFIg/edit?usp=sharing > > > Please do not hesitate to reach out with any questions or concerns. > > Thanks, > Andy > > > Andrew Block > Red Hat Consulting > 101 N. Wacker, Suite 150 > Chicago, IL 60606 > andrew.block at redhat.com | m. (716) 870-2408 > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 05:19:05 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 10:49:05 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: Wanted to clarify something I'd said. :) On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger wrote: > > > On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira < > rmartine at redhat.com> wrote: > >> >> >> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >> wrote: >> >>> As I have written in a previous post I started to write Jenkinsfiles >>> for the helloworld application and I am not sure how will we build >>> docker images. The are 2 ways: >>> >>> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >>> - 'docker build' needs to be root/privileged and will not be allowed >>> to run on OpenShift Online (AFAIK) >>> - can be setup to do a 2-phase build for compiled languages >>> >>> 2) S2I (OpenShift concept [1]) >>> - runs S2I image as non root and commits and tags the resulting image >>> at the end >>> - works on OpenShift Online >>> - harder to setup and work with >>> - does not do a 2-phase build /yet/ for compiled languages as some >>> people think (including myself until today) >>> >>> What type of build are we going to use? >>> >> >> If no one decided yet I'd prefer Source-to-Image since it is more aligned >> with how OpenShift builds application inside docker containers easily. >> Also, based on all our examples inside Red Hat Developers, we have only >> code. No Dockerfiles. One more reason to use S2I. >> > > Right, it was my understanding we'd delegate the building of the images to > OpenShift (kind of one of the main selling points for OS over stock K8s), > which in turn is implemented using s2i. This alleviates the responsibility > of the developer to know anything about image construction; they focus on > their app and choose the deployment target like "EAP" or "Node" and we > abstract away the containerization parts. > I actually am not sure if s2i is a requirement for us; the build of the application is done by a Jenkins job (as defined in a stage in the Jenkinsfile), and then we just need to get that build output into a base image which contains the runtime. How that happens is not necessarily s2i; I could see an easy docker build job just using some Dockerfile like: FROM jboss-eap-7-image cp application.war $JBOSS_HOME/standalone/deployments ...or similar. So TBH I'm a bit unclear what s2i buys us? S, ALR > >> >>> Are we targeting OpenShift Online? >>> >> >> AFAIK, we are targetting whatever the user is running Openshift (either >> locally or remote, no matter if it is Enterprise, Dedicated or Online). >> > > +1. > >> >> >>> >>> Thanks, >>> Tomas >>> >>> [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil >>> ds_and_image_streams.html#source-build >>> >>> S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image >>> s/java.html >>> >>> >>> _______________________________________________ >>> kontinuity-dev-public mailing list >>> kontinuity-dev-public at redhat.com >>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >> >> > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Tue May 3 08:08:29 2016 From: pmuir at redhat.com (Pete Muir) Date: Tue, 3 May 2016 13:38:29 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: On 3 May 2016 at 10:49, Andrew Lee Rubinger wrote: > Wanted to clarify something I'd said. :) > > On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger wrote: >> >> >> >> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira >> wrote: >>> >>> >>> >>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >>> wrote: >>>> >>>> As I have written in a previous post I started to write Jenkinsfiles >>>> for the helloworld application and I am not sure how will we build >>>> docker images. The are 2 ways: >>>> >>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >>>> - 'docker build' needs to be root/privileged and will not be allowed >>>> to run on OpenShift Online (AFAIK) >>>> - can be setup to do a 2-phase build for compiled languages >>>> >>>> 2) S2I (OpenShift concept [1]) >>>> - runs S2I image as non root and commits and tags the resulting image >>>> at the end >>>> - works on OpenShift Online >>>> - harder to setup and work with >>>> - does not do a 2-phase build /yet/ for compiled languages as some >>>> people think (including myself until today) >>>> >>>> What type of build are we going to use? >>> >>> >>> If no one decided yet I'd prefer Source-to-Image since it is more aligned >>> with how OpenShift builds application inside docker containers easily. Also, >>> based on all our examples inside Red Hat Developers, we have only code. No >>> Dockerfiles. One more reason to use S2I. >> >> >> Right, it was my understanding we'd delegate the building of the images to >> OpenShift (kind of one of the main selling points for OS over stock K8s), >> which in turn is implemented using s2i. This alleviates the responsibility >> of the developer to know anything about image construction; they focus on >> their app and choose the deployment target like "EAP" or "Node" and we >> abstract away the containerization parts. > > > I actually am not sure if s2i is a requirement for us; the build of the > application is done by a Jenkins job (as defined in a stage in the > Jenkinsfile), and then we just need to get that build output into a base > image which contains the runtime. How that happens is not necessarily s2i; > I could see an easy docker build job just using some Dockerfile like: > > FROM jboss-eap-7-image > cp application.war $JBOSS_HOME/standalone/deployments > > ...or similar. > > So TBH I'm a bit unclear what s2i buys us? It means you don't have to write that Dockerfile, and it means the build happens inside a container, rather than on bare metal/the VM, which gives you greater build reproducibilty. > > S, > ALR > >>> >>> >>>> >>>> Are we targeting OpenShift Online? >>> >>> >>> AFAIK, we are targetting whatever the user is running Openshift (either >>> locally or remote, no matter if it is Enterprise, Dedicated or Online). >> >> >> +1. >>> >>> >>>> >>>> >>>> Thanks, >>>> Tomas >>>> >>>> [1] - https://docs.openshift.org/latest/architecture/core_concepts/buil >>>> ds_and_image_streams.html#source-build >>>> S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image >>>> s/java.html >>>> >>>> _______________________________________________ >>>> kontinuity-dev-public mailing list >>>> kontinuity-dev-public at redhat.com >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >>> >>> >> >> >> >> -- >> Red Hat Developer Programs Architecture >> @ALRubinger > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > From jstracha at redhat.com Tue May 3 08:39:44 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 09:39:44 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> > On 3 May 2016, at 09:08, Pete Muir wrote: > On 3 May 2016 at 10:49, Andrew Lee Rubinger > wrote: >> Wanted to clarify something I'd said. :) >> >> On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger wrote: >>> >>> >>> >>> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira >>> wrote: >>>> >>>> >>>> >>>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >>>> wrote: >>>>> >>>>> As I have written in a previous post I started to write Jenkinsfiles >>>>> for the helloworld application and I am not sure how will we build >>>>> docker images. The are 2 ways: >>>>> >>>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker build' >>>>> - 'docker build' needs to be root/privileged and will not be allowed >>>>> to run on OpenShift Online (AFAIK) >>>>> - can be setup to do a 2-phase build for compiled languages >>>>> >>>>> 2) S2I (OpenShift concept [1]) >>>>> - runs S2I image as non root and commits and tags the resulting image >>>>> at the end >>>>> - works on OpenShift Online >>>>> - harder to setup and work with >>>>> - does not do a 2-phase build /yet/ for compiled languages as some >>>>> people think (including myself until today) >>>>> >>>>> What type of build are we going to use? >>>> >>>> >>>> If no one decided yet I'd prefer Source-to-Image since it is more aligned >>>> with how OpenShift builds application inside docker containers easily. Also, >>>> based on all our examples inside Red Hat Developers, we have only code. No >>>> Dockerfiles. One more reason to use S2I. >>> >>> >>> Right, it was my understanding we'd delegate the building of the images to >>> OpenShift (kind of one of the main selling points for OS over stock K8s), >>> which in turn is implemented using s2i. This alleviates the responsibility >>> of the developer to know anything about image construction; they focus on >>> their app and choose the deployment target like "EAP" or "Node" and we >>> abstract away the containerization parts. >> >> >> I actually am not sure if s2i is a requirement for us; the build of the >> application is done by a Jenkins job (as defined in a stage in the >> Jenkinsfile), and then we just need to get that build output into a base >> image which contains the runtime. How that happens is not necessarily s2i; >> I could see an easy docker build job just using some Dockerfile like: >> >> FROM jboss-eap-7-image >> cp application.war $JBOSS_HOME/standalone/deployments >> >> ...or similar. >> >> So TBH I'm a bit unclear what s2i buys us? > > It means you don't have to write that Dockerfile, though for many dynamic languages like nodejs/ruby/python you don?t have to write a dockerfile; you can just refer to an ?onbuild? docker file like this: FROM node:5.3-onbuild and you?re done. i.e. you just have to refer to the name and label of the onbuild docker image and you?re done. Though for things like Java this approach doesn?t work so well > and it means the > build happens inside a container, rather than on bare metal/the VM, Even if you use Dockerifles and docker explicitly; thats usually running in a container. e.g. if you use a Jenkinsfile on Kubernetes/OpenShift to make a docker image ?the docker way? with a Dockerfile; its still all running on a container (as are all the steps in a jenkins build if jenkins is hosted inside kubernetes/openshift). > which gives you greater build reproducibilty. The main value proposition of S2I is probably security; it allows you to build docker images without exposing the docker port - which security folks equate to getting root on the bare metal box. For Java folks using OpenShift the S2I binary builds looks the most appealing approach if folks wanna limit access to the docker port; it means you can then run a regular maven/gradle build, make versioned artefacts that get deployed into your nexus/artifactory/mvn repo, then maven can post the jar/war files into S2I binary builds to make the docker image - without needing to expose the docker socket. e.g. using the fabric8 maven plugin; we can do a regular maven release and generate docker images; which works well in a multi-maven module project too. Its very common in Java projects to have many modules in a build; sometimes making multiple docker images. James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 09:15:34 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 14:45:34 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: Sure, I should have been more clear. :) Do we have another mechanism aside s2i that's lighterweight and can alleviate the responsibility of the developer to create the Dockerfile, but just puts a build output into a base image? In many cases that's all we need to do. If s2i ends up being the answer: cool. S, ALR On Tue, May 3, 2016 at 1:38 PM, Pete Muir wrote: > On 3 May 2016 at 10:49, Andrew Lee Rubinger wrote: > > Wanted to clarify something I'd said. :) > > > > On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger > wrote: > >> > >> > >> > >> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira > >> wrote: > >>> > >>> > >>> > >>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka > >>> wrote: > >>>> > >>>> As I have written in a previous post I started to write Jenkinsfiles > >>>> for the helloworld application and I am not sure how will we build > >>>> docker images. The are 2 ways: > >>>> > >>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker > build' > >>>> - 'docker build' needs to be root/privileged and will not be allowed > >>>> to run on OpenShift Online (AFAIK) > >>>> - can be setup to do a 2-phase build for compiled languages > >>>> > >>>> 2) S2I (OpenShift concept [1]) > >>>> - runs S2I image as non root and commits and tags the resulting image > >>>> at the end > >>>> - works on OpenShift Online > >>>> - harder to setup and work with > >>>> - does not do a 2-phase build /yet/ for compiled languages as some > >>>> people think (including myself until today) > >>>> > >>>> What type of build are we going to use? > >>> > >>> > >>> If no one decided yet I'd prefer Source-to-Image since it is more > aligned > >>> with how OpenShift builds application inside docker containers easily. > Also, > >>> based on all our examples inside Red Hat Developers, we have only > code. No > >>> Dockerfiles. One more reason to use S2I. > >> > >> > >> Right, it was my understanding we'd delegate the building of the images > to > >> OpenShift (kind of one of the main selling points for OS over stock > K8s), > >> which in turn is implemented using s2i. This alleviates the > responsibility > >> of the developer to know anything about image construction; they focus > on > >> their app and choose the deployment target like "EAP" or "Node" and we > >> abstract away the containerization parts. > > > > > > I actually am not sure if s2i is a requirement for us; the build of the > > application is done by a Jenkins job (as defined in a stage in the > > Jenkinsfile), and then we just need to get that build output into a base > > image which contains the runtime. How that happens is not necessarily > s2i; > > I could see an easy docker build job just using some Dockerfile like: > > > > FROM jboss-eap-7-image > > cp application.war $JBOSS_HOME/standalone/deployments > > > > ...or similar. > > > > So TBH I'm a bit unclear what s2i buys us? > > It means you don't have to write that Dockerfile, and it means the > build happens inside a container, rather than on bare metal/the VM, > which gives you greater build reproducibilty. > > > > > S, > > ALR > > > >>> > >>> > >>>> > >>>> Are we targeting OpenShift Online? > >>> > >>> > >>> AFAIK, we are targetting whatever the user is running Openshift (either > >>> locally or remote, no matter if it is Enterprise, Dedicated or Online). > >> > >> > >> +1. > >>> > >>> > >>>> > >>>> > >>>> Thanks, > >>>> Tomas > >>>> > >>>> [1] - > https://docs.openshift.org/latest/architecture/core_concepts/buil > >>>> ds_and_image_streams.html#source-build > >>>> S2I for Java - > https://docs.openshift.org/latest/using_images/s2i_image > >>>> s/java.html > >>>> > >>>> _______________________________________________ > >>>> kontinuity-dev-public mailing list > >>>> kontinuity-dev-public at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > >>> > >>> > >> > >> > >> > >> -- > >> Red Hat Developer Programs Architecture > >> @ALRubinger > > > > > > > > > > -- > > Red Hat Developer Programs Architecture > > @ALRubinger > > > > _______________________________________________ > > kontinuity-dev-public mailing list > > kontinuity-dev-public at redhat.com > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Tue May 3 09:19:17 2016 From: pmuir at redhat.com (Pete Muir) Date: Tue, 3 May 2016 14:49:17 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: On 3 May 2016 at 14:45, Andrew Lee Rubinger wrote: > Sure, I should have been more clear. :) > > Do we have another mechanism aside s2i that's lighterweight and can > alleviate the responsibility of the developer to create the Dockerfile, but > just puts a build output into a base image? In many cases that's all we > need to do. If s2i ends up being the answer: cool. I don't know, but don't you also need to run the build in a container? > > S, > ALR > > On Tue, May 3, 2016 at 1:38 PM, Pete Muir wrote: >> >> On 3 May 2016 at 10:49, Andrew Lee Rubinger wrote: >> > Wanted to clarify something I'd said. :) >> > >> > On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger >> > wrote: >> >> >> >> >> >> >> >> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira >> >> wrote: >> >>> >> >>> >> >>> >> >>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >> >>> wrote: >> >>>> >> >>>> As I have written in a previous post I started to write Jenkinsfiles >> >>>> for the helloworld application and I am not sure how will we build >> >>>> docker images. The are 2 ways: >> >>>> >> >>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker >> >>>> build' >> >>>> - 'docker build' needs to be root/privileged and will not be allowed >> >>>> to run on OpenShift Online (AFAIK) >> >>>> - can be setup to do a 2-phase build for compiled languages >> >>>> >> >>>> 2) S2I (OpenShift concept [1]) >> >>>> - runs S2I image as non root and commits and tags the resulting >> >>>> image >> >>>> at the end >> >>>> - works on OpenShift Online >> >>>> - harder to setup and work with >> >>>> - does not do a 2-phase build /yet/ for compiled languages as some >> >>>> people think (including myself until today) >> >>>> >> >>>> What type of build are we going to use? >> >>> >> >>> >> >>> If no one decided yet I'd prefer Source-to-Image since it is more >> >>> aligned >> >>> with how OpenShift builds application inside docker containers easily. >> >>> Also, >> >>> based on all our examples inside Red Hat Developers, we have only >> >>> code. No >> >>> Dockerfiles. One more reason to use S2I. >> >> >> >> >> >> Right, it was my understanding we'd delegate the building of the images >> >> to >> >> OpenShift (kind of one of the main selling points for OS over stock >> >> K8s), >> >> which in turn is implemented using s2i. This alleviates the >> >> responsibility >> >> of the developer to know anything about image construction; they focus >> >> on >> >> their app and choose the deployment target like "EAP" or "Node" and we >> >> abstract away the containerization parts. >> > >> > >> > I actually am not sure if s2i is a requirement for us; the build of the >> > application is done by a Jenkins job (as defined in a stage in the >> > Jenkinsfile), and then we just need to get that build output into a base >> > image which contains the runtime. How that happens is not necessarily >> > s2i; >> > I could see an easy docker build job just using some Dockerfile like: >> > >> > FROM jboss-eap-7-image >> > cp application.war $JBOSS_HOME/standalone/deployments >> > >> > ...or similar. >> > >> > So TBH I'm a bit unclear what s2i buys us? >> >> It means you don't have to write that Dockerfile, and it means the >> build happens inside a container, rather than on bare metal/the VM, >> which gives you greater build reproducibilty. >> >> > >> > S, >> > ALR >> > >> >>> >> >>> >> >>>> >> >>>> Are we targeting OpenShift Online? >> >>> >> >>> >> >>> AFAIK, we are targetting whatever the user is running Openshift >> >>> (either >> >>> locally or remote, no matter if it is Enterprise, Dedicated or >> >>> Online). >> >> >> >> >> >> +1. >> >>> >> >>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Tomas >> >>>> >> >>>> [1] - >> >>>> https://docs.openshift.org/latest/architecture/core_concepts/buil >> >>>> ds_and_image_streams.html#source-build >> >>>> S2I for Java - >> >>>> https://docs.openshift.org/latest/using_images/s2i_image >> >>>> s/java.html >> >>>> >> >>>> _______________________________________________ >> >>>> kontinuity-dev-public mailing list >> >>>> kontinuity-dev-public at redhat.com >> >>>> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Red Hat Developer Programs Architecture >> >> @ALRubinger >> > >> > >> > >> > >> > -- >> > Red Hat Developer Programs Architecture >> > @ALRubinger >> > >> > _______________________________________________ >> > kontinuity-dev-public mailing list >> > kontinuity-dev-public at redhat.com >> > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> > > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger From jstracha at redhat.com Tue May 3 09:50:06 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 10:50:06 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: > On 3 May 2016, at 10:15, Andrew Lee Rubinger wrote: > > Sure, I should have been more clear. :) > > Do we have another mechanism aside s2i that's lighterweight and can alleviate the responsibility of the developer to create the Dockerfile, but just puts a build output into a base image? In many cases that's all we need to do. If s2i ends up being the answer: cool. For Java folks we can use the fabric8 maven plugin; which can either use s2i binary builds under the covers, or if you expose the docker socket it can make images using ?traditional docker?. The docker maven plugin generates a Dockerfile on the fly if you don?t specify one. Its designed so that we can take any existing Java / maven project and easily dockerize it with a minimum of developer interaction. The fabric8 console then makes it easy to just take any maven project, dockerize & kubeify it then add a Jenkins pipeline without developers needing to know anything about maven / docker / S2I / Jenkins etc. James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 10:43:09 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 16:13:09 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> Message-ID: Now *that's* interesting. :) Added to my TODO to flesh out how we want to do the container builds, and more fully understand the scope/features of s2i. Invoking the new pipeline build just merged into Origin is the focus of Catapult development this week now that we have end-to-end plumbing work done. S, ALR On Tue, May 3, 2016 at 3:20 PM, James Strachan wrote: > > On 3 May 2016, at 10:15, Andrew Lee Rubinger wrote: > > Sure, I should have been more clear. :) > > Do we have another mechanism aside s2i that's lighterweight and can > alleviate the responsibility of the developer to create the Dockerfile, but > just puts a build output into a base image? In many cases that's all we > need to do. If s2i ends up being the answer: cool. > > > For Java folks we can use the fabric8 maven plugin; which can either use > s2i binary builds under the covers, or if you expose the docker socket it > can make images using ?traditional docker?. > > The docker maven plugin generates a Dockerfile on the fly if you don?t > specify one. Its designed so that we can take any existing Java / maven > project and easily dockerize it with a minimum of developer interaction. > The fabric8 console then makes it easy to just take any maven project, > dockerize & kubeify it then add a Jenkins pipeline without developers > needing to know anything about maven / docker / S2I / Jenkins etc. > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhuss at redhat.com Tue May 3 11:26:04 2016 From: rhuss at redhat.com (Roland Huss) Date: Tue, 3 May 2016 13:26:04 +0200 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> Message-ID: <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> One big issue developers will have is build times, regardless whether to use a two-phase strategy or plain S2I. The reason is that you need to obtain your Maven dependencies which is easily in the 100MB+ range (including deps, transitive deps + plugins with their deps). For S2I you have two possibilities to speed this up currently: * Use a Nexus proxy close to you * Use incremental builds and copy over the ~/.m2 from build to build. Both are better than fetching all stuff afresh, but still, I couldn't get a vanilla build of our quickstarts (e.g. cdi-camel) to take much less than four minutes (last time I tested was half a year ago, though). The only solution I see to substantially speed this up is to volume mount a ~/.m2 repository *with the required dependencies* to the builder image. Not an easy task for a generic S2I builder image. This might all be ok for CI / CD, but for a daily developer workflow with many turnarounds personally I wouldn't be happy to use S2I. --- Therefore for the fabric8-maven-plugin we currently try a different approach, with two selectable strategies: * For situations where you have access to a Docker daemon and a registry (within OpenShift), we build a Docker image and push it to the registry. You can do this with a Dockerfile included but also without Dockerfile. In the simplest case (the 'wildfly-swarm' or 'spring-boot' case), with zero config (but opinionatedd defaults) * For the OpenShift case, we will use a BinaryBuildSource with DockerBuildStrategy in a BuildConfig. This means, we create *offine* a docker.tar (with Dockerfile, again, created automatically + artifacts), create the corresponding BuildConfig and feed this tar to OpenShift for a binary build. The benefit is that we keep the project specific dependencies locally, reusable for each run. Compilation of the artifacts happens also locally (as developers are used to). We are still not there yet, though. The reworked plugin can be found at https://github.com/fabric8io/fabric8-maven-plugin which has much more feature like 'enrichers' which can add to the resource descriptors by simply declaring dependencies in the pom.xml (much like spring-boot starters) and more. This is still WIP, but I hope to have something to demo very soon. ... roland >> On 3 May 2016, at 09:08, Pete Muir > > wrote: >> On 3 May 2016 at 10:49, Andrew Lee Rubinger > > wrote: >>> Wanted to clarify something I'd said. :) >>> >>> On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger >> > wrote: >>>> >>>> >>>> >>>> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira >>>> > wrote: >>>>> >>>>> >>>>> >>>>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >>>> > >>>>> wrote: >>>>>> >>>>>> As I have written in a previous post I started to write Jenkinsfiles >>>>>> for the helloworld application and I am not sure how will we build >>>>>> docker images. The are 2 ways: >>>>>> >>>>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker >>>>>> build' >>>>>> - 'docker build' needs to be root/privileged and will not be allowed >>>>>> to run on OpenShift Online (AFAIK) >>>>>> - can be setup to do a 2-phase build for compiled languages >>>>>> >>>>>> 2) S2I (OpenShift concept [1]) >>>>>> - runs S2I image as non root and commits and tags the resulting image >>>>>> at the end >>>>>> - works on OpenShift Online >>>>>> - harder to setup and work with >>>>>> - does not do a 2-phase build /yet/ for compiled languages as some >>>>>> people think (including myself until today) >>>>>> >>>>>> What type of build are we going to use? >>>>> >>>>> >>>>> If no one decided yet I'd prefer Source-to-Image since it is more >>>>> aligned >>>>> with how OpenShift builds application inside docker containers >>>>> easily. Also, >>>>> based on all our examples inside Red Hat Developers, we have only >>>>> code. No >>>>> Dockerfiles. One more reason to use S2I. >>>> >>>> >>>> Right, it was my understanding we'd delegate the building of the >>>> images to >>>> OpenShift (kind of one of the main selling points for OS over stock >>>> K8s), >>>> which in turn is implemented using s2i. This alleviates the >>>> responsibility >>>> of the developer to know anything about image construction; they >>>> focus on >>>> their app and choose the deployment target like "EAP" or "Node" and we >>>> abstract away the containerization parts. >>> >>> >>> I actually am not sure if s2i is a requirement for us; the build of the >>> application is done by a Jenkins job (as defined in a stage in the >>> Jenkinsfile), and then we just need to get that build output into a base >>> image which contains the runtime. How that happens is not >>> necessarily s2i; >>> I could see an easy docker build job just using some Dockerfile like: >>> >>> FROM jboss-eap-7-image >>> cp application.war $JBOSS_HOME/standalone/deployments >>> >>> ...or similar. >>> >>> So TBH I'm a bit unclear what s2i buys us? >> >> It means you don't have to write that Dockerfile, > > though for many dynamic languages like nodejs/ruby/python you don?t have > to write a dockerfile; you can just refer to an ?onbuild? docker file > like this: > > FROM node:5.3-onbuild > > and you?re done. i.e. you just have to refer to the name and label of > the onbuild docker image and you?re done. > > Though for things like Java this approach doesn?t work so well > > >> and it means the >> build happens inside a container, rather than on bare metal/the VM, > > Even if you use Dockerifles and docker explicitly; thats usually running > in a container. e.g. if you use a Jenkinsfile on Kubernetes/OpenShift to > make a docker image ?the docker way? with a Dockerfile; its still all > running on a container (as are all the steps in a jenkins build if > jenkins is hosted inside kubernetes/openshift). > > > >> which gives you greater build reproducibilty. > > The main value proposition of S2I is probably security; it allows you to > build docker images without exposing the docker port - which security > folks equate to getting root on the bare metal box. > > For Java folks using OpenShift the S2I binary builds looks the most > appealing approach if folks wanna limit access to the docker port; it > means you can then run a regular maven/gradle build, make versioned > artefacts that get deployed into your nexus/artifactory/mvn repo, then > maven can post the jar/war files into S2I binary builds to make the > docker image - without needing to expose the docker socket. e.g. using > the fabric8 maven plugin; we can do a regular maven release and generate > docker images; which works well in a multi-maven module project too. Its > very common in Java projects to have many modules in a build; sometimes > making multiple docker images. > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > From jstracha at redhat.com Tue May 3 11:38:10 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 12:38:10 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> Message-ID: <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> > On 3 May 2016, at 12:26, Roland Huss wrote: > > One big issue developers will have is build times, regardless > whether to use a two-phase strategy or plain S2I. The reason is that > you need to obtain your Maven dependencies which is easily in the > 100MB+ range (including deps, transitive deps + plugins with their > deps). > > For S2I you have two possibilities to speed this up currently: > > * Use a Nexus proxy close to you > * Use incremental builds and copy over the ~/.m2 from build to build. Using a persistent volume for ~/.m2/repository in the builder image would be a nice idea; so that it can be shared between builds without having to copy maven repos into docker images each build and all that jazz. James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Tue May 3 11:39:11 2016 From: pmuir at redhat.com (Pete Muir) Date: Tue, 3 May 2016 17:09:11 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> Message-ID: I agree that having this option would be useful, but I'm not sure it's great for a CI situation. I would typically want to (default to) a clean room environment in CI. On 3 May 2016 at 17:08, James Strachan wrote: > > On 3 May 2016, at 12:26, Roland Huss wrote: > > One big issue developers will have is build times, regardless > whether to use a two-phase strategy or plain S2I. The reason is that > you need to obtain your Maven dependencies which is easily in the > 100MB+ range (including deps, transitive deps + plugins with their > deps). > > For S2I you have two possibilities to speed this up currently: > > * Use a Nexus proxy close to you > * Use incremental builds and copy over the ~/.m2 from build to build. > > > Using a persistent volume for ~/.m2/repository in the builder image would be > a nice idea; so that it can be shared between builds without having to copy > maven repos into docker images each build and all that jazz. > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > From jstracha at redhat.com Tue May 3 11:44:05 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 12:44:05 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> Message-ID: <34A1410B-40B3-48EF-89D3-DF5B8B5320D0@redhat.com> > On 3 May 2016, at 12:39, Pete Muir wrote: > > I agree that having this option would be useful, but I'm not sure it's > great for a CI situation. I would typically want to (default to) a > clean room environment in CI. Agreed - I see this more as an optimisation for developer builds when they are working ?pre commit?. Using an empty maven repo (and just using nexus) is good practice for when you do releases (i.e. post commit). The result of that maven repo can also be handy to know really which jars were required/used to do the builds + tests. > > On 3 May 2016 at 17:08, James Strachan wrote: >> >> On 3 May 2016, at 12:26, Roland Huss wrote: >> >> One big issue developers will have is build times, regardless >> whether to use a two-phase strategy or plain S2I. The reason is that >> you need to obtain your Maven dependencies which is easily in the >> 100MB+ range (including deps, transitive deps + plugins with their >> deps). >> >> For S2I you have two possibilities to speed this up currently: >> >> * Use a Nexus proxy close to you >> * Use incremental builds and copy over the ~/.m2 from build to build. >> >> >> Using a persistent volume for ~/.m2/repository in the builder image would be >> a nice idea; so that it can be shared between builds without having to copy >> maven repos into docker images each build and all that jazz. >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: https://medium.com/@jstrachan/ >> >> fabric8: http://fabric8.io/ >> open source microservices platform >> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 11:43:32 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 17:13:32 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> Message-ID: Thanks for raising this, Roland. I've been muling over exactly this issue lately because: 1) Starting with a "fresh" dependencies repository (ie. empty ~/.m2/repository) means your builds are reproducible to whatever degree your remote repos are immutable; you're not carrying build artifacts from prior builds which may muss things up. 2) Getting all your dependencies to populate a repository with dependencies can take forever. What I'm not yet grokking (and this is likely because I have some catchup to do), is how s2i vs. fabric8-maven-plugin is related; we still need to build the application to have an artifact to containerize. And it's that build, which is before any Docker stuff, which is the one which presents the problem. S, ALR On Tue, May 3, 2016 at 4:56 PM, Roland Huss wrote: > One big issue developers will have is build times, regardless > whether to use a two-phase strategy or plain S2I. The reason is that > you need to obtain your Maven dependencies which is easily in the > 100MB+ range (including deps, transitive deps + plugins with their > deps). > > For S2I you have two possibilities to speed this up currently: > > * Use a Nexus proxy close to you > * Use incremental builds and copy over the ~/.m2 from build to build. > > Both are better than fetching all stuff afresh, but still, I couldn't > get a vanilla build of our quickstarts (e.g. cdi-camel) to take much > less than four minutes (last time I tested was half a year ago, > though). > > The only solution I see to substantially speed this up is to volume > mount a ~/.m2 repository *with the required dependencies* to the > builder image. Not an easy task for a generic S2I builder image. > > This might all be ok for CI / CD, but for a daily developer workflow > with many turnarounds personally I wouldn't be happy to use S2I. > > --- > > Therefore for the fabric8-maven-plugin we currently try a different > approach, with two selectable strategies: > > * For situations where you have access to a Docker daemon and a > registry (within OpenShift), we build a Docker image and push it to > the registry. You can do this with a Dockerfile included but also > without Dockerfile. In the simplest case (the 'wildfly-swarm' or > 'spring-boot' case), with zero config (but opinionatedd defaults) > > * For the OpenShift case, we will use a BinaryBuildSource with > DockerBuildStrategy in a BuildConfig. This means, we create *offine* > a docker.tar (with Dockerfile, again, created automatically + > artifacts), create the corresponding BuildConfig and feed this tar > to OpenShift for a binary build. The benefit is that we keep the > project specific dependencies locally, reusable for each run. > Compilation of the artifacts happens also locally (as developers are > used to). > > We are still not there yet, though. The reworked plugin can be found > at https://github.com/fabric8io/fabric8-maven-plugin which has much > more feature like 'enrichers' which can add to the resource > descriptors by simply declaring dependencies in the pom.xml (much like > spring-boot starters) and more. > > This is still WIP, but I hope to have something to demo very soon. > > ... roland > > >> On 3 May 2016, at 09:08, Pete Muir >> > wrote: > >> On 3 May 2016 at 10:49, Andrew Lee Rubinger >> > wrote: > >>> Wanted to clarify something I'd said. :) > >>> > >>> On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger >>> > wrote: > >>>> > >>>> > >>>> > >>>> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira > >>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >>>>> > > >>>>> wrote: > >>>>>> > >>>>>> As I have written in a previous post I started to write Jenkinsfiles > >>>>>> for the helloworld application and I am not sure how will we build > >>>>>> docker images. The are 2 ways: > >>>>>> > >>>>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker > >>>>>> build' > >>>>>> - 'docker build' needs to be root/privileged and will not be allowed > >>>>>> to run on OpenShift Online (AFAIK) > >>>>>> - can be setup to do a 2-phase build for compiled languages > >>>>>> > >>>>>> 2) S2I (OpenShift concept [1]) > >>>>>> - runs S2I image as non root and commits and tags the resulting > image > >>>>>> at the end > >>>>>> - works on OpenShift Online > >>>>>> - harder to setup and work with > >>>>>> - does not do a 2-phase build /yet/ for compiled languages as some > >>>>>> people think (including myself until today) > >>>>>> > >>>>>> What type of build are we going to use? > >>>>> > >>>>> > >>>>> If no one decided yet I'd prefer Source-to-Image since it is more > >>>>> aligned > >>>>> with how OpenShift builds application inside docker containers > >>>>> easily. Also, > >>>>> based on all our examples inside Red Hat Developers, we have only > >>>>> code. No > >>>>> Dockerfiles. One more reason to use S2I. > >>>> > >>>> > >>>> Right, it was my understanding we'd delegate the building of the > >>>> images to > >>>> OpenShift (kind of one of the main selling points for OS over stock > >>>> K8s), > >>>> which in turn is implemented using s2i. This alleviates the > >>>> responsibility > >>>> of the developer to know anything about image construction; they > >>>> focus on > >>>> their app and choose the deployment target like "EAP" or "Node" and we > >>>> abstract away the containerization parts. > >>> > >>> > >>> I actually am not sure if s2i is a requirement for us; the build of the > >>> application is done by a Jenkins job (as defined in a stage in the > >>> Jenkinsfile), and then we just need to get that build output into a > base > >>> image which contains the runtime. How that happens is not > >>> necessarily s2i; > >>> I could see an easy docker build job just using some Dockerfile like: > >>> > >>> FROM jboss-eap-7-image > >>> cp application.war $JBOSS_HOME/standalone/deployments > >>> > >>> ...or similar. > >>> > >>> So TBH I'm a bit unclear what s2i buys us? > >> > >> It means you don't have to write that Dockerfile, > > > > though for many dynamic languages like nodejs/ruby/python you don?t have > > to write a dockerfile; you can just refer to an ?onbuild? docker file > > like this: > > > > FROM node:5.3-onbuild > > > > and you?re done. i.e. you just have to refer to the name and label of > > the onbuild docker image and you?re done. > > > > Though for things like Java this approach doesn?t work so well > > > > > >> and it means the > >> build happens inside a container, rather than on bare metal/the VM, > > > > Even if you use Dockerifles and docker explicitly; thats usually running > > in a container. e.g. if you use a Jenkinsfile on Kubernetes/OpenShift to > > make a docker image ?the docker way? with a Dockerfile; its still all > > running on a container (as are all the steps in a jenkins build if > > jenkins is hosted inside kubernetes/openshift). > > > > > > > >> which gives you greater build reproducibilty. > > > > The main value proposition of S2I is probably security; it allows you to > > build docker images without exposing the docker port - which security > > folks equate to getting root on the bare metal box. > > > > For Java folks using OpenShift the S2I binary builds looks the most > > appealing approach if folks wanna limit access to the docker port; it > > means you can then run a regular maven/gradle build, make versioned > > artefacts that get deployed into your nexus/artifactory/mvn repo, then > > maven can post the jar/war files into S2I binary builds to make the > > docker image - without needing to expose the docker socket. e.g. using > > the fabric8 maven plugin; we can do a regular maven release and generate > > docker images; which works well in a multi-maven module project too. Its > > very common in Java projects to have many modules in a build; sometimes > > making multiple docker images. > > > > James > > ------- > > Red Hat > > > > Twitter: @jstrachan > > Email: jstracha at redhat.com > > Blog: https://medium.com/@jstrachan/ > > > > fabric8: http://fabric8.io/ > > open source microservices platform > > > > > > > > _______________________________________________ > > kontinuity-dev-public mailing list > > kontinuity-dev-public at redhat.com > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Tue May 3 11:49:22 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 12:49:22 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> Message-ID: <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> > On 3 May 2016, at 12:43, Andrew Lee Rubinger wrote: > > Thanks for raising this, Roland. I've been muling over exactly this issue lately because: > > 1) Starting with a "fresh" dependencies repository (ie. empty ~/.m2/repository) means your builds are reproducible to whatever degree your remote repos are immutable; you're not carrying build artifacts from prior builds which may muss things up. > 2) Getting all your dependencies to populate a repository with dependencies can take forever. > > What I'm not yet grokking (and this is likely because I have some catchup to do), is how s2i vs. fabric8-maven-plugin is related; we still need to build the application to have an artifact to containerize. And it's that build, which is before any Docker stuff, which is the one which presents the problem. s2i can use source builds (where you build everything using s2i shell scripts and a builder docker image), you can use s2i binary builds or - if you have access to the docker socket - you can use ?regular docker build? stuff. With the s2i binary builds your regular build engine (maven/gradle/whatever) makes the binary tarball that gets included in the docker image (e.g. the jar/war) and posts it to s2i - then the s2i binary builder just takes that docker tarball and makes the docker image for you. So the fabric8 maven plugin can invoke the s2i binary build process along with the rest of your maven build; making all the versioned artefacts, deploying them to your maven repository, tagging git and also making and tagging the docker image. So the release then becomes a regular maven build as java folks are used to doing. James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartine at redhat.com Tue May 3 11:51:09 2016 From: rmartine at redhat.com (Ricardo Martinelli de Oliveira) Date: Tue, 3 May 2016 08:51:09 -0300 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> Message-ID: On Tue, May 3, 2016 at 8:26 AM, Roland Huss wrote: > One big issue developers will have is build times, regardless > whether to use a two-phase strategy or plain S2I. The reason is that > you need to obtain your Maven dependencies which is easily in the > 100MB+ range (including deps, transitive deps + plugins with their > deps). > > For S2I you have two possibilities to speed this up currently: > > * Use a Nexus proxy close to you > * Use incremental builds and copy over the ~/.m2 from build to build. > > Both are better than fetching all stuff afresh, but still, I couldn't > get a vanilla build of our quickstarts (e.g. cdi-camel) to take much > less than four minutes (last time I tested was half a year ago, > though). > I tested the OpenShift Online Developer Preview instance and they could make a Java S2I build (using the jboss-eap-quickstart) run in 1 minute and 10 seconds. Maybe ask the OpenShift Online Ops team what they did to decrease this build time? > > The only solution I see to substantially speed this up is to volume > mount a ~/.m2 repository *with the required dependencies* to the > builder image. Not an easy task for a generic S2I builder image. > > This might all be ok for CI / CD, but for a daily developer workflow > with many turnarounds personally I wouldn't be happy to use S2I. > > --- > > Therefore for the fabric8-maven-plugin we currently try a different > approach, with two selectable strategies: > > * For situations where you have access to a Docker daemon and a > registry (within OpenShift), we build a Docker image and push it to > the registry. You can do this with a Dockerfile included but also > without Dockerfile. In the simplest case (the 'wildfly-swarm' or > 'spring-boot' case), with zero config (but opinionatedd defaults) > > * For the OpenShift case, we will use a BinaryBuildSource with > DockerBuildStrategy in a BuildConfig. This means, we create *offine* > a docker.tar (with Dockerfile, again, created automatically + > artifacts), create the corresponding BuildConfig and feed this tar > to OpenShift for a binary build. The benefit is that we keep the > project specific dependencies locally, reusable for each run. > Compilation of the artifacts happens also locally (as developers are > used to). > > We are still not there yet, though. The reworked plugin can be found > at https://github.com/fabric8io/fabric8-maven-plugin which has much > more feature like 'enrichers' which can add to the resource > descriptors by simply declaring dependencies in the pom.xml (much like > spring-boot starters) and more. > > This is still WIP, but I hope to have something to demo very soon. > > ... roland > > >> On 3 May 2016, at 09:08, Pete Muir >> > wrote: > >> On 3 May 2016 at 10:49, Andrew Lee Rubinger >> > wrote: > >>> Wanted to clarify something I'd said. :) > >>> > >>> On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger >>> > wrote: > >>>> > >>>> > >>>> > >>>> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira > >>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka >>>>> > > >>>>> wrote: > >>>>>> > >>>>>> As I have written in a previous post I started to write Jenkinsfiles > >>>>>> for the helloworld application and I am not sure how will we build > >>>>>> docker images. The are 2 ways: > >>>>>> > >>>>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker > >>>>>> build' > >>>>>> - 'docker build' needs to be root/privileged and will not be allowed > >>>>>> to run on OpenShift Online (AFAIK) > >>>>>> - can be setup to do a 2-phase build for compiled languages > >>>>>> > >>>>>> 2) S2I (OpenShift concept [1]) > >>>>>> - runs S2I image as non root and commits and tags the resulting > image > >>>>>> at the end > >>>>>> - works on OpenShift Online > >>>>>> - harder to setup and work with > >>>>>> - does not do a 2-phase build /yet/ for compiled languages as some > >>>>>> people think (including myself until today) > >>>>>> > >>>>>> What type of build are we going to use? > >>>>> > >>>>> > >>>>> If no one decided yet I'd prefer Source-to-Image since it is more > >>>>> aligned > >>>>> with how OpenShift builds application inside docker containers > >>>>> easily. Also, > >>>>> based on all our examples inside Red Hat Developers, we have only > >>>>> code. No > >>>>> Dockerfiles. One more reason to use S2I. > >>>> > >>>> > >>>> Right, it was my understanding we'd delegate the building of the > >>>> images to > >>>> OpenShift (kind of one of the main selling points for OS over stock > >>>> K8s), > >>>> which in turn is implemented using s2i. This alleviates the > >>>> responsibility > >>>> of the developer to know anything about image construction; they > >>>> focus on > >>>> their app and choose the deployment target like "EAP" or "Node" and we > >>>> abstract away the containerization parts. > >>> > >>> > >>> I actually am not sure if s2i is a requirement for us; the build of the > >>> application is done by a Jenkins job (as defined in a stage in the > >>> Jenkinsfile), and then we just need to get that build output into a > base > >>> image which contains the runtime. How that happens is not > >>> necessarily s2i; > >>> I could see an easy docker build job just using some Dockerfile like: > >>> > >>> FROM jboss-eap-7-image > >>> cp application.war $JBOSS_HOME/standalone/deployments > >>> > >>> ...or similar. > >>> > >>> So TBH I'm a bit unclear what s2i buys us? > >> > >> It means you don't have to write that Dockerfile, > > > > though for many dynamic languages like nodejs/ruby/python you don?t have > > to write a dockerfile; you can just refer to an ?onbuild? docker file > > like this: > > > > FROM node:5.3-onbuild > > > > and you?re done. i.e. you just have to refer to the name and label of > > the onbuild docker image and you?re done. > > > > Though for things like Java this approach doesn?t work so well > > > > > >> and it means the > >> build happens inside a container, rather than on bare metal/the VM, > > > > Even if you use Dockerifles and docker explicitly; thats usually running > > in a container. e.g. if you use a Jenkinsfile on Kubernetes/OpenShift to > > make a docker image ?the docker way? with a Dockerfile; its still all > > running on a container (as are all the steps in a jenkins build if > > jenkins is hosted inside kubernetes/openshift). > > > > > > > >> which gives you greater build reproducibilty. > > > > The main value proposition of S2I is probably security; it allows you to > > build docker images without exposing the docker port - which security > > folks equate to getting root on the bare metal box. > > > > For Java folks using OpenShift the S2I binary builds looks the most > > appealing approach if folks wanna limit access to the docker port; it > > means you can then run a regular maven/gradle build, make versioned > > artefacts that get deployed into your nexus/artifactory/mvn repo, then > > maven can post the jar/war files into S2I binary builds to make the > > docker image - without needing to expose the docker socket. e.g. using > > the fabric8 maven plugin; we can do a regular maven release and generate > > docker images; which works well in a multi-maven module project too. Its > > very common in Java projects to have many modules in a build; sometimes > > making multiple docker images. > > > > James > > ------- > > Red Hat > > > > Twitter: @jstrachan > > Email: jstracha at redhat.com > > Blog: https://medium.com/@jstrachan/ > > > > fabric8: http://fabric8.io/ > > open source microservices platform > > > > > > > > _______________________________________________ > > kontinuity-dev-public mailing list > > kontinuity-dev-public at redhat.com > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Tue May 3 12:27:07 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 13:27:07 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> Message-ID: > On 3 May 2016, at 12:45, Andrew Lee Rubinger > wrote: > > But then don't we risk breaking reproducibility if some job puts in a -SNAPSHOT of some GAV and another job picks it up? Great point! :) I guess for the ?developer builds? we?d want each developer to have their own persistent volume maybe? Then these volumes don?t get used at all for ?release builds?? > I could see if for a persistent m2 repo to only hold released (immutable) artifacts, and a separate repo for SNAPSHOTs, and then we clear that from build to build. Its a little hard to do that; unless we explicitly keep clearing all snapshot versions before/after builds? James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Tue May 3 12:37:33 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 18:07:33 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> Message-ID: On Tue, May 3, 2016 at 5:57 PM, James Strachan wrote: > On 3 May 2016, at 12:45, Andrew Lee Rubinger wrote: > > But then don't we risk breaking reproducibility if some job puts in a > -SNAPSHOT of some GAV and another job picks it up? > > > Great point! :) > > I guess for the ?developer builds? we?d want each developer to have their > own persistent volume maybe? Then these volumes don?t get used at all for > ?release builds?? > I think persistent volumes can be shared so long as they only contain releases, and only are backed by a single remote repo (ie. JBoss Nexus). If you start to point to N remote repos, you lose namespacing in the GAV because it's "first downloaded wins" and GAVs are not coordinates that are unique between different remote repos. But yeah bottom line if the "cached" repo contains only immutable releases it can be shared. > > > I could see if for a persistent m2 repo to only hold released (immutable) > artifacts, and a separate repo for SNAPSHOTs, and then we clear that from > build to build. > > > Its a little hard to do that; unless we explicitly keep clearing all > snapshot versions before/after builds? > Exactly; keep one persistent "releases" repo which may be shared (because it's read-only), and then each job has a SNAPSHOTs repo which is clear at the start of each build. That ensures we don't have stale artifacts lying around while still safely caching the majority of dependencies for speed. S, ALR > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Tue May 3 12:38:55 2016 From: pmuir at redhat.com (Pete Muir) Date: Tue, 3 May 2016 18:08:55 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <5FB1300B-1D52-49CF-AF35-F927D8CCB577@redhat.com> Message-ID: The approach we took in OpenShift Online 2.x (a co-located proxy cache) seemed to work very well to me. On 3 May 2016 at 18:07, Andrew Lee Rubinger wrote: > > > On Tue, May 3, 2016 at 5:57 PM, James Strachan wrote: >> >> On 3 May 2016, at 12:45, Andrew Lee Rubinger wrote: >> >> But then don't we risk breaking reproducibility if some job puts in a >> -SNAPSHOT of some GAV and another job picks it up? >> >> >> Great point! :) >> >> I guess for the ?developer builds? we?d want each developer to have their >> own persistent volume maybe? Then these volumes don?t get used at all for >> ?release builds?? > > > I think persistent volumes can be shared so long as they only contain > releases, and only are backed by a single remote repo (ie. JBoss Nexus). If > you start to point to N remote repos, you lose namespacing in the GAV > because it's "first downloaded wins" and GAVs are not coordinates that are > unique between different remote repos. > > But yeah bottom line if the "cached" repo contains only immutable releases > it can be shared. > >> >> >> >> I could see if for a persistent m2 repo to only hold released (immutable) >> artifacts, and a separate repo for SNAPSHOTs, and then we clear that from >> build to build. >> >> >> Its a little hard to do that; unless we explicitly keep clearing all >> snapshot versions before/after builds? > > > Exactly; keep one persistent "releases" repo which may be shared (because > it's read-only), and then each job has a SNAPSHOTs repo which is clear at > the start of each build. That ensures we don't have stale artifacts lying > around while still safely caching the majority of dependencies for speed. > > S, > ALR > >> >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: https://medium.com/@jstrachan/ >> >> fabric8: http://fabric8.io/ >> open source microservices platform >> > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > From rhuss at redhat.com Tue May 3 12:56:43 2016 From: rhuss at redhat.com (Roland Huss) Date: Tue, 3 May 2016 14:56:43 +0200 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> Message-ID: > So the fabric8 maven plugin can invoke the s2i binary build process > along with the rest of your maven build; making all the versioned > artefacts, deploying them to your maven repository, tagging git and also > making and tagging the docker image. So the release then becomes a > regular maven build as java folks are used to doing. To be technically correct, its not a "S2I Binary Build" but only a "Docker Build Strategy" with a "Binary Build Source" (in contrast to a "S2I Build Strategy" with a "Git Repository Source") [1]. But otherwise its correct. The main difference is that in the binary case Maven is running locally on the Dev machine (and the result is pushed as tar to OpenShift), whereas in the S2I case its running in a builder image within OpenShift ... Just early afternoon nit-picking ;-) ... ... roland [1]: https://docs.openshift.org/latest/dev_guide/builds.html > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > From jstracha at redhat.com Tue May 3 13:39:56 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 3 May 2016 14:39:56 +0100 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> Message-ID: <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> > On 3 May 2016, at 13:56, Roland Huss wrote: > >> So the fabric8 maven plugin can invoke the s2i binary build process >> along with the rest of your maven build; making all the versioned >> artefacts, deploying them to your maven repository, tagging git and also >> making and tagging the docker image. So the release then becomes a >> regular maven build as java folks are used to doing. > > To be technically correct, its not a "S2I Binary Build" but only a > "Docker Build Strategy" with a "Binary Build Source" (in contrast to a > "S2I Build Strategy" with a "Git Repository Source") [1]. I?ve seen it referred to as a few different things ;). I guess the doc calls it an STI ?binary source? build? https://docs.openshift.org/latest/dev_guide/builds.html#binary-source I thought docker build strategy was a different thing; using a custom docker image to build the image? > But otherwise > its correct. The main difference is that in the binary case Maven is > running locally on the Dev machine (and the result is pushed as tar to > OpenShift), whereas in the S2I case its running in a builder image > within OpenShift ... > > Just early afternoon nit-picking ;-) ? no worries - would love to know the right term to refer to the STI ?binary source? builds. > > ... roland > > > [1]: https://docs.openshift.org/latest/dev_guide/builds.html > >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: https://medium.com/@jstrachan/ >> >> fabric8: http://fabric8.io/ >> open source microservices platform >> James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From ablock at redhat.com Tue May 3 13:42:02 2016 From: ablock at redhat.com (Andrew Block) Date: Tue, 3 May 2016 09:42:02 -0400 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> Message-ID: A picture is worth a thousand words as I?ve run into this at customer sites. Here is a blog I put together on binary builds with a diagram on the different build types and strategies http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/ Hope it helps clarify things for other that may still have some confusion on the subjects - Andy ? Andrew Block Red Hat Consulting 101 N. Wacker, Suite 150 Chicago, IL 60606 andrew.block at redhat.com?| m. (716) 870-2408 On May 3, 2016 at 9:39:25 AM, James Strachan (jstracha at redhat.com) wrote: On 3 May 2016, at 13:56, Roland Huss wrote: So the fabric8 maven plugin can invoke the s2i binary build process along with the rest of your maven build; making all the versioned artefacts, deploying them to your maven repository, tagging git and also making and tagging the docker image. So the release then becomes a regular maven build as java folks are used to doing. To be technically correct, its not a "S2I Binary Build" but only a "Docker Build Strategy" with a "Binary Build Source" ?(in contrast to a "S2I Build Strategy" with a "Git Repository Source") [1]. I?ve seen it referred to as a few different things ;). I guess the doc calls it an STI ??binary source? build? https://docs.openshift.org/latest/dev_guide/builds.html#binary-source I thought docker build strategy was a different thing; using a custom docker image to build the image? But otherwise its correct. The main difference is that in the binary case Maven is running locally on the Dev machine (and the result is pushed as tar to OpenShift), whereas in the S2I case its running in a builder image within OpenShift ... Just early afternoon nit-picking ;-) ? no worries - would love to know the right term to refer to the STI ??binary source? builds. ... roland [1]: https://docs.openshift.org/latest/dev_guide/builds.html James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform _______________________________________________ kontinuity-dev-public mailing list kontinuity-dev-public at redhat.com https://www.redhat.com/mailman/listinfo/kontinuity-dev-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhuss at redhat.com Tue May 3 13:45:19 2016 From: rhuss at redhat.com (Roland Huss) Date: Tue, 3 May 2016 15:45:19 +0200 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> Message-ID: > I tested the OpenShift Online Developer Preview instance and they could > make a Java S2I build (using the jboss-eap-quickstart) run in 1 minute > and 10 seconds. Maybe ask the OpenShift Online Ops team what they did to > decrease this build time? Cool, sounds great. How can I get an account for the OpenShift Online Developer Preview ? My tests were solely against a single VM with a one node OpenShift setup at that time ('hope that's a realistic scenario for a local Developer workflow). I will redo the timing it with the current CDK. ... roland > > > The only solution I see to substantially speed this up is to volume > mount a ~/.m2 repository *with the required dependencies* to the > builder image. Not an easy task for a generic S2I builder image. > > This might all be ok for CI / CD, but for a daily developer workflow > with many turnarounds personally I wouldn't be happy to use S2I. > > --- > > Therefore for the fabric8-maven-plugin we currently try a different > approach, with two selectable strategies: > > * For situations where you have access to a Docker daemon and a > registry (within OpenShift), we build a Docker image and push it to > the registry. You can do this with a Dockerfile included but also > without Dockerfile. In the simplest case (the 'wildfly-swarm' or > 'spring-boot' case), with zero config (but opinionatedd defaults) > > * For the OpenShift case, we will use a BinaryBuildSource with > DockerBuildStrategy in a BuildConfig. This means, we create *offine* > a docker.tar (with Dockerfile, again, created automatically + > artifacts), create the corresponding BuildConfig and feed this tar > to OpenShift for a binary build. The benefit is that we keep the > project specific dependencies locally, reusable for each run. > Compilation of the artifacts happens also locally (as developers are > used to). > > We are still not there yet, though. The reworked plugin can be found > at https://github.com/fabric8io/fabric8-maven-plugin which has much > more feature like 'enrichers' which can add to the resource > descriptors by simply declaring dependencies in the pom.xml (much like > spring-boot starters) and more. > > This is still WIP, but I hope to have something to demo very soon. > > ... roland > > >> On 3 May 2016, at 09:08, Pete Muir > >> >> wrote: > >> On 3 May 2016 at 10:49, Andrew Lee Rubinger > >> >> wrote: > >>> Wanted to clarify something I'd said. :) > >>> > >>> On Tue, May 3, 2016 at 6:18 AM, Andrew Lee Rubinger > >>> >> wrote: > >>>> > >>>> > >>>> > >>>> On Tue, May 3, 2016 at 12:14 AM, Ricardo Martinelli de Oliveira > >>>> > >> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Mon, May 2, 2016 at 3:39 PM, Tomas Nozicka > >>>>> >> > >>>>> wrote: > >>>>>> > >>>>>> As I have written in a previous post I started to write > Jenkinsfiles > >>>>>> for the helloworld application and I am not sure how will we > build > >>>>>> docker images. The are 2 ways: > >>>>>> > >>>>>> 1) [Classic] Build it in your Jenkins job/build and call 'docker > >>>>>> build' > >>>>>> - 'docker build' needs to be root/privileged and will not be > allowed > >>>>>> to run on OpenShift Online (AFAIK) > >>>>>> - can be setup to do a 2-phase build for compiled languages > >>>>>> > >>>>>> 2) S2I (OpenShift concept [1]) > >>>>>> - runs S2I image as non root and commits and tags the > resulting image > >>>>>> at the end > >>>>>> - works on OpenShift Online > >>>>>> - harder to setup and work with > >>>>>> - does not do a 2-phase build /yet/ for compiled languages as > some > >>>>>> people think (including myself until today) > >>>>>> > >>>>>> What type of build are we going to use? > >>>>> > >>>>> > >>>>> If no one decided yet I'd prefer Source-to-Image since it is more > >>>>> aligned > >>>>> with how OpenShift builds application inside docker containers > >>>>> easily. Also, > >>>>> based on all our examples inside Red Hat Developers, we have only > >>>>> code. No > >>>>> Dockerfiles. One more reason to use S2I. > >>>> > >>>> > >>>> Right, it was my understanding we'd delegate the building of the > >>>> images to > >>>> OpenShift (kind of one of the main selling points for OS over stock > >>>> K8s), > >>>> which in turn is implemented using s2i. This alleviates the > >>>> responsibility > >>>> of the developer to know anything about image construction; they > >>>> focus on > >>>> their app and choose the deployment target like "EAP" or "Node" > and we > >>>> abstract away the containerization parts. > >>> > >>> > >>> I actually am not sure if s2i is a requirement for us; the build > of the > >>> application is done by a Jenkins job (as defined in a stage in the > >>> Jenkinsfile), and then we just need to get that build output > into a base > >>> image which contains the runtime. How that happens is not > >>> necessarily s2i; > >>> I could see an easy docker build job just using some Dockerfile > like: > >>> > >>> FROM jboss-eap-7-image > >>> cp application.war $JBOSS_HOME/standalone/deployments > >>> > >>> ...or similar. > >>> > >>> So TBH I'm a bit unclear what s2i buys us? > >> > >> It means you don't have to write that Dockerfile, > > > > though for many dynamic languages like nodejs/ruby/python you > don?t have > > to write a dockerfile; you can just refer to an ?onbuild? docker file > > like this: > > > > FROM node:5.3-onbuild > > > > and you?re done. i.e. you just have to refer to the name and label of > > the onbuild docker image and you?re done. > > > > Though for things like Java this approach doesn?t work so well > > > > > >> and it means the > >> build happens inside a container, rather than on bare metal/the VM, > > > > Even if you use Dockerifles and docker explicitly; thats usually > running > > in a container. e.g. if you use a Jenkinsfile on > Kubernetes/OpenShift to > > make a docker image ?the docker way? with a Dockerfile; its still all > > running on a container (as are all the steps in a jenkins build if > > jenkins is hosted inside kubernetes/openshift). > > > > > > > >> which gives you greater build reproducibilty. > > > > The main value proposition of S2I is probably security; it allows > you to > > build docker images without exposing the docker port - which security > > folks equate to getting root on the bare metal box. > > > > For Java folks using OpenShift the S2I binary builds looks the most > > appealing approach if folks wanna limit access to the docker port; it > > means you can then run a regular maven/gradle build, make versioned > > artefacts that get deployed into your nexus/artifactory/mvn repo, then > > maven can post the jar/war files into S2I binary builds to make the > > docker image - without needing to expose the docker socket. e.g. using > > the fabric8 maven plugin; we can do a regular maven release and > generate > > docker images; which works well in a multi-maven module project > too. Its > > very common in Java projects to have many modules in a build; > sometimes > > making multiple docker images. > > > > James > > ------- > > Red Hat > > > > Twitter: @jstrachan > > Email: jstracha at redhat.com > > > > Blog: https://medium.com/@jstrachan/ > > > > fabric8: http://fabric8.io/ > > open source microservices platform > > > > > > > > _______________________________________________ > > kontinuity-dev-public mailing list > > kontinuity-dev-public at redhat.com > > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > From rhuss at redhat.com Tue May 3 13:55:43 2016 From: rhuss at redhat.com (Roland Huss) Date: Tue, 3 May 2016 15:55:43 +0200 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> Message-ID: <762b9de9-b4d5-5ba4-5dc9-765f01f2d2e7@redhat.com> > I?ve seen it referred to as a few different things ;). I guess the doc > calls it an STI ?binary source? build? > https://docs.openshift.org/latest/dev_guide/builds.html#binary-source S2I is a 'build strategy' which can be combined with multiple 'build sources', a 'binary source' is one of them. However, what I was talking about was a 'Docker build strategy' (as opossed to a 'S2I build strategy') which uses a 'binary source' (== tar created by the Maven plugin). > I thought docker build strategy was a different thing; using a custom > docker image to build the image? No, we don't use any builder image but the 'docker build strategy' which simply uploads the tar via OpenShift API (much like when doing plain Docker builds with a Docker daemon), which in turn creates an ImageStream used in the build. So instead of (S2I, Git or Binary) --> (Docker, Binary) ... roland > >> But otherwise >> its correct. The main difference is that in the binary case Maven is >> running locally on the Dev machine (and the result is pushed as tar to >> OpenShift), whereas in the S2I case its running in a builder image >> within OpenShift ... >> >> Just early afternoon nit-picking ;-) ? > > no worries - would love to know the right term to refer to the STI > ?binary source? builds. > > >> >> ... roland >> >> >> [1]: https://docs.openshift.org/latest/dev_guide/builds.html >> >>> >>> James >>> ------- >>> Red Hat >>> >>> Twitter: @jstrachan >>> Email: jstracha at redhat.com >>> >>> Blog: https://medium.com/@jstrachan/ >>> >>> fabric8: http://fabric8.io/ >>> open source microservices platform >>> > > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: https://medium.com/@jstrachan/ > > fabric8: http://fabric8.io/ > open source microservices platform > From alr at redhat.com Tue May 3 14:57:01 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 3 May 2016 20:27:01 +0530 Subject: [kontinuity-dev-public] S2I vs. docker build In-Reply-To: <762b9de9-b4d5-5ba4-5dc9-765f01f2d2e7@redhat.com> References: <1462214359.15706.103.camel@redhat.com> <0904AA0D-0190-4DF1-ADC5-F3E289462F96@redhat.com> <1e97b6dd-fd27-2311-a772-192ce629cb31@redhat.com> <04FB6288-6B8E-4B33-9FA5-E19D16513397@redhat.com> <36A34BDF-6FAE-4DCB-937D-BA15544AF8A8@redhat.com> <762b9de9-b4d5-5ba4-5dc9-765f01f2d2e7@redhat.com> Message-ID: Great discussion, all, and I'd like it to continue. As we may be wading into some product concerns I'll request we continue this on the internal "distortion at redhat.com", copied here. New posts can drop "kontinuity-dev-public" for time time being, and we can post a public summary when done or when we're certain we're clear of internal affairs. S, ALR On Tue, May 3, 2016 at 7:25 PM, Roland Huss wrote: > > > > I?ve seen it referred to as a few different things ;). I guess the doc > > calls it an STI ?binary source? build? > > https://docs.openshift.org/latest/dev_guide/builds.html#binary-source > > S2I is a 'build strategy' which can be combined with multiple 'build > sources', a 'binary source' is one of them. > > However, what I was talking about was a 'Docker build strategy' (as > opossed to a 'S2I build strategy') which uses a 'binary source' (== tar > created by the Maven plugin). > > > I thought docker build strategy was a different thing; using a custom > > docker image to build the image? > > No, we don't use any builder image but the 'docker build strategy' which > simply uploads the tar via OpenShift API (much like when doing plain > Docker builds with a Docker daemon), which in turn creates an > ImageStream used in the build. > > So instead of (S2I, Git or Binary) --> (Docker, Binary) > > ... roland > > > > > > > >> But otherwise > >> its correct. The main difference is that in the binary case Maven is > >> running locally on the Dev machine (and the result is pushed as tar to > >> OpenShift), whereas in the S2I case its running in a builder image > >> within OpenShift ... > >> > >> Just early afternoon nit-picking ;-) ? > > > > no worries - would love to know the right term to refer to the STI > > ?binary source? builds. > > > > > >> > >> ... roland > >> > >> > >> [1]: https://docs.openshift.org/latest/dev_guide/builds.html > >> > >>> > >>> James > >>> ------- > >>> Red Hat > >>> > >>> Twitter: @jstrachan > >>> Email: jstracha at redhat.com > >>> > >>> Blog: https://medium.com/@jstrachan/ > >>> > >>> fabric8: http://fabric8.io/ > >>> open source microservices platform > >>> > > > > > > James > > ------- > > Red Hat > > > > Twitter: @jstrachan > > Email: jstracha at redhat.com > > Blog: https://medium.com/@jstrachan/ > > > > fabric8: http://fabric8.io/ > > open source microservices platform > > > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohei at nozaki.me Sun May 8 13:11:10 2016 From: kohei at nozaki.me (Kohei Nozaki) Date: Sun, 8 May 2016 22:11:10 +0900 Subject: [kontinuity-dev-public] Integration test failure on catapult-service-openshift-impl In-Reply-To: References: <44ff6434-7cbc-6a43-8e63-7ce7f9b7c46f@nozaki.me> <0b243ff6-b46e-e36a-cc0f-0536cf9f4caf@nozaki.me> Message-ID: <7dde5a66-5f0d-bf20-9522-3dde974cee4f@nozaki.me> Hi Andrew, Thanks for the advice, now I've succeeded to make OS X + VM combo work, not sure what was the cause of first failure (unexpected end of stream on...) though. I guess the cause would be missing or wrong the env var KONTINUITY_CATAPULT_OPENSHIFT_URL, or I had forgot to stop firewalld. Kohei On 5/1/16 11:58, Andrew Lee Rubinger wrote: > Ah, that makes a lot of sense given that additional context; the tests > are needing to reach the host; I wonder if exposing the ports you need > from your VM to your host and then manually specifying the env var or > sysprop KONTINUITY_CATAPULT_OPENSHIFT_URL should do it for you. > > Basically if you can run OpenShift in your VM and then from a > brower/curl on your host execute requests against the VM-running > OpenShift API, you should be good to go. > > S, > ALR > > On Sun, May 1, 2016 at 6:58 AM, Kohei Nozaki > wrote: > > Hi Andrew, > > Good news: I've just succeeded to run integration tests, in an > all-in-one CentOS7 VM, Running tests in a VM is not comfortable though. > > The cause seems like some network layer problem because my first try > was with a combo of OS X host (runs Catapult tests and WildFly) and > CentOS7 guest (runs Docker and OpenShift) which is living in VMware > Fusion. > > I followed this instruction to setup OpenShift: > https://github.com/openshift/origin/blob/master/CONTRIBUTING.adoc#download-from-github > > But anyway I need to investigate how to make OS X + VM combo work > before start working on the project. any hints about it would be > greatly appreciated. > > Thanks, > > Kohei > > On 4/30/16 14:47, Andrew Lee Rubinger wrote: > > Hey Kohel: > > Welcome! Though I haven't seen this error yet either locally or > in our > CI environments, let's see what we can do. > > So the relevant error is in your connecting to OpenShift: > > io.fabric8.kubernetes.client.KubernetesClientException: An > error has > occurred. > Caused by: java.io.IOException: unexpected end of stream on > com.squareup.okhttp.Address at e5a03a78 > Caused by: java.io.EOFException: \n not found: size=7 > content=15030100020216... > > I'm guessing you followed the instructions to get OpenShift running > locally; if you hadn't I think you'd be seeing some variant of > ConnectException: > > Caused by: > io.fabric8.kubernetes.client.KubernetesClientException: An > error has occurred. > Caused by: java.net.ConnectException: Failed to connect to > localhost/127.0.0.1:8443 > > > Can you let us know which method you've chosen to run > OpenShift? I've > been testing here against a local build of OpenShift Origin master. > > Beyond that I see some similar complaints in the okhttp tracker: > > https://github.com/square/okhttp/issues/1741 > > ...perhaps the Fabric8 team has some better insights as they're > consuming the lib; will ping @iocanel. > > S, > ALR > > On Sat, Apr 30, 2016 at 7:42 AM, Kohei Nozaki > >> wrote: > > Hello, > > I'm trying to run Catapult's integration test cases following > README, but it doesn't work for me. > > Build log: > > https://gist.github.com/lbtc-xxx/9aaddf84d11986e0dc84f979545a28e0 > > Relevant part of failsafe-reports: > > http://people.apache.org/~kohei/failsafe-reports-openshift-service-impl/ > > I'm newbie of Docker / OpenShift so maybe it's caused by easy > mistake, but I don't know what it is. could you give me any > hints to > make it work? > > Thanks. > > Kohei > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > > > > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger From alr at redhat.com Tue May 17 17:06:35 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Tue, 17 May 2016 13:06:35 -0400 Subject: [kontinuity-dev-public] Fwd: [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: Moving to the public list. :) We can drop "continuous-dev" in replies. S, ALR ---------- Forwarded message ---------- From: Xavier Coulon Date: Tue, May 17, 2016 at 12:50 PM Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift To: continuous-dev at redhat.com Hello, For the Catapult project, we need to programmatically create a project on OpenShift 3 and then configure it with a Jenkins pipeline so that any build eventually results in the deployment of a new version of the service. Ben already provided some OpenShift templates for both Jenkins and a sample project, and my current understanding is that the pipeline template for the sample app describes all the services, routes, build configurations, image streams, etc., including the Jenkins pipeline (a groovy script) nested in a BuildConfig resource. But on the Catapult side, if I run these lines of code (where pipelineTemplate is the content of the `pipelinetemplate.json` file): final Template template = client.templates().load(pipelineTemplate ).get(); client.templates().inNamespace("openshift").create(template); then I have the template created, but this obviously can only be executed once, and it does not seem attached to any particular project. What I'm really trying to understand is: - what kind of config file should we have along with an application in a GitHub repositories (ie, quickstarts, etc.): a full OpenShift template file, a Jenkinsfile, something else/something more ? - how, with Fabric8 OpenShift client, can I submit a request similar to what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything setup in my project ? Any response (or clarification if I misunderstood something !) will be very welcome :-) Thanks Best regards, /Xavier -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Tue May 17 17:10:00 2016 From: bparees at redhat.com (Ben Parees) Date: Tue, 17 May 2016 13:10:00 -0400 Subject: [kontinuity-dev-public] Fwd: [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: invoking "create" with a template object just creates a template resource object (what we call registering it...making it available in etcd), it doesn't instantiate the template (ie actually creating the resource objects defined by the template). Instantiating the template means posting it to the processtemplate endpoint, getting back a template object that has had parameter substitution applied, and then iterating the objects in the result template and creating each one. Jeff (on CC) can probably point you to java code that will do this. On Tue, May 17, 2016 at 1:06 PM, Andrew Lee Rubinger wrote: > Moving to the public list. :) We can drop "continuous-dev" in replies. > > S, > ALR > > ---------- Forwarded message ---------- > From: Xavier Coulon > Date: Tue, May 17, 2016 at 12:50 PM > Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift > To: continuous-dev at redhat.com > > > Hello, > > For the Catapult project, we need to programmatically create a project on > OpenShift 3 and then configure it with a Jenkins pipeline so that any build > eventually results in the deployment of a new version of the service. > Ben already provided some OpenShift templates for both Jenkins and a > sample project, and my current understanding is that the pipeline template > for the sample app describes all the services, routes, build > configurations, image streams, etc., including the Jenkins pipeline (a > groovy script) nested in a BuildConfig resource. > > But on the Catapult side, if I run these lines of code (where > pipelineTemplate is the content of the `pipelinetemplate.json` file): > > final Template template = client.templates().load(pipelineTemplate > ).get(); > client.templates().inNamespace("openshift").create(template); > > then I have the template created, but this obviously can only be executed > once, and it does not seem attached to any particular project. > > What I'm really trying to understand is: > - what kind of config file should we have along with an application in a > GitHub repositories (ie, quickstarts, etc.): a full OpenShift template > file, a Jenkinsfile, something else/something more ? > - how, with Fabric8 OpenShift client, can I submit a request similar to > what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything > setup in my project ? > > Any response (or clarification if I misunderstood something !) will be > very welcome :-) > > Thanks > Best regards, > /Xavier > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrawling at redhat.com Tue May 17 17:15:19 2016 From: jrawling at redhat.com (James Rawlings) Date: Tue, 17 May 2016 18:15:19 +0100 Subject: [kontinuity-dev-public] [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: If you're using the the fabric8 kubernetes-workflow plugin then there's a step which handles all of this in the Jenkinsfile https://github.com/fabric8io/kubernetes-workflow/tree/master/devops-steps#applying-kubernetes-configuration it uses the kubernetes client under the hood and optionally performs rolling upgrades when updating apps. Cheers, James. -- James Rawlings Engineering Red Hat, Inc. Blog: https://medium.com/@jdrawlings Twitter: @jdrawlings http://fabric8.io https://blog.fabric8.io/ Open Source microservices platform > On 17 May 2016, at 18:06, Andrew Lee Rubinger wrote: > > Moving to the public list. :) We can drop "continuous-dev" in replies. > > S, > ALR > ---------- Forwarded message ---------- > From: Xavier Coulon > > Date: Tue, May 17, 2016 at 12:50 PM > Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift > To: continuous-dev at redhat.com > > > Hello, > > For the Catapult project, we need to programmatically create a project on OpenShift 3 and then configure it with a Jenkins pipeline so that any build eventually results in the deployment of a new version of the service. > Ben already provided some OpenShift templates for both Jenkins and a sample project, and my current understanding is that the pipeline template for the sample app describes all the services, routes, build configurations, image streams, etc., including the Jenkins pipeline (a groovy script) nested in a BuildConfig resource. > > But on the Catapult side, if I run these lines of code (where pipelineTemplate is the content of the `pipelinetemplate.json` file): > > final Template template = client.templates().load(pipelineTemplate).get(); > client.templates().inNamespace("openshift").create(template); > > then I have the template created, but this obviously can only be executed once, and it does not seem attached to any particular project. > > What I'm really trying to understand is: > - what kind of config file should we have along with an application in a GitHub repositories (ie, quickstarts, etc.): a full OpenShift template file, a Jenkinsfile, something else/something more ? > - how, with Fabric8 OpenShift client, can I submit a request similar to what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything setup in my project ? > > Any response (or clarification if I misunderstood something !) will be very welcome :-) > > Thanks > Best regards, > /Xavier > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Tue May 17 17:29:29 2016 From: bparees at redhat.com (Ben Parees) Date: Tue, 17 May 2016 13:29:29 -0400 Subject: [kontinuity-dev-public] [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: On Tue, May 17, 2016 at 1:15 PM, James Rawlings wrote: > If you're using the the fabric8 kubernetes-workflow plugin then there's a > step which handles all of this in the Jenkinsfile > https://github.com/fabric8io/kubernetes-workflow/tree/master/devops-steps#applying-kubernetes-configuration it > uses the kubernetes client under the hood and optionally performs rolling > upgrades when updating apps. > ?that looks like it handles creating resources, but does it handle processing/instantiating from a template json? ? > > Cheers, James. > > -- > James Rawlings > Engineering > Red Hat, Inc. > Blog: https://medium.com/@jdrawlings > Twitter: @jdrawlings > > http://fabric8.io > https://blog.fabric8.io/ > Open Source microservices platform > > > > > > > On 17 May 2016, at 18:06, Andrew Lee Rubinger wrote: > > Moving to the public list. :) We can drop "continuous-dev" in replies. > > S, > ALR > ---------- Forwarded message ---------- > From: Xavier Coulon > Date: Tue, May 17, 2016 at 12:50 PM > Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift > To: continuous-dev at redhat.com > > > Hello, > > For the Catapult project, we need to programmatically create a project on > OpenShift 3 and then configure it with a Jenkins pipeline so that any build > eventually results in the deployment of a new version of the service. > Ben already provided some OpenShift templates for both Jenkins and a > sample project, and my current understanding is that the pipeline template > for the sample app describes all the services, routes, build > configurations, image streams, etc., including the Jenkins pipeline (a > groovy script) nested in a BuildConfig resource. > > But on the Catapult side, if I run these lines of code (where > pipelineTemplate is the content of the `pipelinetemplate.json` file): > > final Template template = client.templates().load(pipelineTemplate > ).get(); > client.templates().inNamespace("openshift").create(template); > > then I have the template created, but this obviously can only be executed > once, and it does not seem attached to any particular project. > > What I'm really trying to understand is: > - what kind of config file should we have along with an application in a > GitHub repositories (ie, quickstarts, etc.): a full OpenShift template > file, a Jenkinsfile, something else/something more ? > - how, with Fabric8 OpenShift client, can I submit a request similar to > what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything > setup in my project ? > > Any response (or clarification if I misunderstood something !) will be > very welcome :-) > > Thanks > Best regards, > /Xavier > > > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrawling at redhat.com Tue May 17 17:33:32 2016 From: jrawling at redhat.com (James Rawlings) Date: Tue, 17 May 2016 18:33:32 +0100 Subject: [kontinuity-dev-public] [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: This example here actually returns a template https://github.com/fabric8io/jenkins-workflow-library/blob/master/workflows/node/CanaryReleaseStageAndApprovePromote/Jenkinsfile#L18-L27 The kuberetesApply will take an OpenShift Template or Kubernetes List and either create / apply a rolling update. Here's the basic template in the example.. https://github.com/fabric8io/jenkins-workflow-library/blob/master/vars/getKubernetesJson.groovy#L12 -- James Rawlings Engineering Red Hat, Inc. Blog: https://medium.com/@jdrawlings Twitter: @jdrawlings http://fabric8.io https://blog.fabric8.io/ Open Source microservices platform > On 17 May 2016, at 18:29, Ben Parees wrote: > > > > On Tue, May 17, 2016 at 1:15 PM, James Rawlings > wrote: > If you're using the the fabric8 kubernetes-workflow plugin then there's a step which handles all of this in the Jenkinsfile https://github.com/fabric8io/kubernetes-workflow/tree/master/devops-steps#applying-kubernetes-configuration it uses the kubernetes client under the hood and optionally performs rolling upgrades when updating apps. > > ?that looks like it handles creating resources, but does it handle processing/instantiating from a template json? > ? > > Cheers, James. > > -- > James Rawlings > Engineering > Red Hat, Inc. > Blog: https://medium.com/@jdrawlings > Twitter: @jdrawlings > > http://fabric8.io > https://blog.fabric8.io/ > Open Source microservices platform > > > > > > >> On 17 May 2016, at 18:06, Andrew Lee Rubinger > wrote: >> >> Moving to the public list. :) We can drop "continuous-dev" in replies. >> >> S, >> ALR >> ---------- Forwarded message ---------- >> From: Xavier Coulon > >> Date: Tue, May 17, 2016 at 12:50 PM >> Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift >> To: continuous-dev at redhat.com >> >> >> Hello, >> >> For the Catapult project, we need to programmatically create a project on OpenShift 3 and then configure it with a Jenkins pipeline so that any build eventually results in the deployment of a new version of the service. >> Ben already provided some OpenShift templates for both Jenkins and a sample project, and my current understanding is that the pipeline template for the sample app describes all the services, routes, build configurations, image streams, etc., including the Jenkins pipeline (a groovy script) nested in a BuildConfig resource. >> >> But on the Catapult side, if I run these lines of code (where pipelineTemplate is the content of the `pipelinetemplate.json` file): >> >> final Template template = client.templates().load(pipelineTemplate).get(); >> client.templates().inNamespace("openshift").create(template); >> >> then I have the template created, but this obviously can only be executed once, and it does not seem attached to any particular project. >> >> What I'm really trying to understand is: >> - what kind of config file should we have along with an application in a GitHub repositories (ie, quickstarts, etc.): a full OpenShift template file, a Jenkinsfile, something else/something more ? >> - how, with Fabric8 OpenShift client, can I submit a request similar to what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything setup in my project ? >> >> Any response (or clarification if I misunderstood something !) will be very welcome :-) >> >> Thanks >> Best regards, >> /Xavier >> >> >> >> -- >> Red Hat Developer Programs Architecture >> @ALRubinger > > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > > > > -- > Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrawling at redhat.com Tue May 17 17:36:22 2016 From: jrawling at redhat.com (James Rawlings) Date: Tue, 17 May 2016 18:36:22 +0100 Subject: [kontinuity-dev-public] [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: <9952064B-F58B-4082-929C-767264F0B117@redhat.com> If you wanted to create the resources programmatically rather than using JSON then you can still do that in groovy using the kubernetes client. Here's an example of using the kubernetes-client directly in a groovy function https://github.com/fabric8io/jenkins-workflow-library/blob/master/vars/performCanaryRelease.groovy#L32 > On 17 May 2016, at 18:33, James Rawlings wrote: > > This example here actually returns a template https://github.com/fabric8io/jenkins-workflow-library/blob/master/workflows/node/CanaryReleaseStageAndApprovePromote/Jenkinsfile#L18-L27 > > The kuberetesApply will take an OpenShift Template or Kubernetes List and either create / apply a rolling update. > > Here's the basic template in the example.. https://github.com/fabric8io/jenkins-workflow-library/blob/master/vars/getKubernetesJson.groovy#L12 > > > -- > James Rawlings > Engineering > Red Hat, Inc. > Blog: https://medium.com/@jdrawlings > Twitter: @jdrawlings > > http://fabric8.io > https://blog.fabric8.io/ > Open Source microservices platform > > > > > > >> On 17 May 2016, at 18:29, Ben Parees > wrote: >> >> >> >> On Tue, May 17, 2016 at 1:15 PM, James Rawlings > wrote: >> If you're using the the fabric8 kubernetes-workflow plugin then there's a step which handles all of this in the Jenkinsfile https://github.com/fabric8io/kubernetes-workflow/tree/master/devops-steps#applying-kubernetes-configuration it uses the kubernetes client under the hood and optionally performs rolling upgrades when updating apps. >> >> ?that looks like it handles creating resources, but does it handle processing/instantiating from a template json? >> ? >> >> Cheers, James. >> >> -- >> James Rawlings >> Engineering >> Red Hat, Inc. >> Blog: https://medium.com/@jdrawlings >> Twitter: @jdrawlings >> >> http://fabric8.io >> https://blog.fabric8.io/ >> Open Source microservices platform >> >> >> >> >> >> >>> On 17 May 2016, at 18:06, Andrew Lee Rubinger > wrote: >>> >>> Moving to the public list. :) We can drop "continuous-dev" in replies. >>> >>> S, >>> ALR >>> ---------- Forwarded message ---------- >>> From: Xavier Coulon > >>> Date: Tue, May 17, 2016 at 12:50 PM >>> Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift >>> To: continuous-dev at redhat.com >>> >>> >>> Hello, >>> >>> For the Catapult project, we need to programmatically create a project on OpenShift 3 and then configure it with a Jenkins pipeline so that any build eventually results in the deployment of a new version of the service. >>> Ben already provided some OpenShift templates for both Jenkins and a sample project, and my current understanding is that the pipeline template for the sample app describes all the services, routes, build configurations, image streams, etc., including the Jenkins pipeline (a groovy script) nested in a BuildConfig resource. >>> >>> But on the Catapult side, if I run these lines of code (where pipelineTemplate is the content of the `pipelinetemplate.json` file): >>> >>> final Template template = client.templates().load(pipelineTemplate).get(); >>> client.templates().inNamespace("openshift").create(template); >>> >>> then I have the template created, but this obviously can only be executed once, and it does not seem attached to any particular project. >>> >>> What I'm really trying to understand is: >>> - what kind of config file should we have along with an application in a GitHub repositories (ie, quickstarts, etc.): a full OpenShift template file, a Jenkinsfile, something else/something more ? >>> - how, with Fabric8 OpenShift client, can I submit a request similar to what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything setup in my project ? >>> >>> Any response (or clarification if I misunderstood something !) will be very welcome :-) >>> >>> Thanks >>> Best regards, >>> /Xavier >>> >>> >>> >>> -- >>> Red Hat Developer Programs Architecture >>> @ALRubinger >> >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> >> >> >> -- >> Ben Parees | OpenShift > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcantril at redhat.com Tue May 17 18:34:32 2016 From: jcantril at redhat.com (Jeff Cantrill) Date: Tue, 17 May 2016 14:34:32 -0400 Subject: [kontinuity-dev-public] Fwd: [Catapult] Configuring the Jenkins pipeline on OpenShift In-Reply-To: References: <64E2B7D2-F904-4A50-88EE-B87268FD7239@redhat.com> Message-ID: On Tue, May 17, 2016 at 1:10 PM, Ben Parees wrote: > invoking "create" with a template object just creates a template resource > object (what we call registering it...making it available in etcd), it > doesn't instantiate the template (ie actually creating the resource objects > defined by the template). > > Instantiating the template means posting it to the processtemplate > endpoint, getting back a template object that has had parameter > substitution applied, and then iterating the objects in the result template > and creating each one. > > Using the f8 openshift client, reference https://github.com/fabric8io/kubernetes-client/blob/b4dd0d898d2d0640d9ac3c73fc85c7996f6ae7c5/kubernetes-examples/src/main/java/io/fabric8/openshift/examples/TemplateExample.java for processing and applying a template > Jeff (on CC) can probably point you to java code that will do this. > > > On Tue, May 17, 2016 at 1:06 PM, Andrew Lee Rubinger > wrote: > >> Moving to the public list. :) We can drop "continuous-dev" in replies. >> >> S, >> ALR >> >> ---------- Forwarded message ---------- >> From: Xavier Coulon >> Date: Tue, May 17, 2016 at 12:50 PM >> Subject: [Catapult] Configuring the Jenkins pipeline on OpenShift >> To: continuous-dev at redhat.com >> >> >> Hello, >> >> For the Catapult project, we need to programmatically create a project on >> OpenShift 3 and then configure it with a Jenkins pipeline so that any build >> eventually results in the deployment of a new version of the service. >> Ben already provided some OpenShift templates for both Jenkins and a >> sample project, and my current understanding is that the pipeline template >> for the sample app describes all the services, routes, build >> configurations, image streams, etc., including the Jenkins pipeline (a >> groovy script) nested in a BuildConfig resource. >> >> But on the Catapult side, if I run these lines of code (where >> pipelineTemplate is the content of the `pipelinetemplate.json` file): >> >> final Template template = client.templates().load( >> pipelineTemplate).get(); >> client.templates().inNamespace("openshift").create(template); >> >> then I have the template created, but this obviously can only be executed >> once, and it does not seem attached to any particular project. >> >> What I'm really trying to understand is: >> - what kind of config file should we have along with an application in a >> GitHub repositories (ie, quickstarts, etc.): a full OpenShift template >> file, a Jenkinsfile, something else/something more ? >> - how, with Fabric8 OpenShift client, can I submit a request similar to >> what `oc new-app -f pipelinetemplate.json` does from CLI, to get everything >> setup in my project ? >> >> Any response (or clarification if I misunderstood something !) will be >> very welcome :-) >> >> Thanks >> Best regards, >> /Xavier >> >> >> >> -- >> Red Hat Developer Programs Architecture >> @ALRubinger >> >> _______________________________________________ >> kontinuity-dev-public mailing list >> kontinuity-dev-public at redhat.com >> https://www.redhat.com/mailman/listinfo/kontinuity-dev-public >> >> > > > -- > Ben Parees | OpenShift > > -- -- Jeff Cantrill Senior Software Engineer, Red Hat Engineering OpenShift Integration Services Red Hat, Inc. *Office*: 703-748-4420 | 866-546-8970 ext. 8162420 jcantril at redhat.com http://www.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Wed May 18 22:56:37 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Wed, 18 May 2016 18:56:37 -0400 Subject: [kontinuity-dev-public] Catapult Development: Now Run Against the ADB Message-ID: I've updated the Catapult README to reflect that the ADB will be our delivery target, and we can (and should) be doing our local testing against the ADB and a "latest" snapshot Origin release from Docker Hub. https://github.com/redhat-kontinuity/catapult/commit/f41e1078785baaaa21d2cf45d2042111c8b770e3 The build will continue to not be reproducible until we're depending upon an ADB release which is pointed to a release of Origin with our features, but I think this'll be fine until mid-June or so for us. Anyone doing Catapult dev please switch to do so against the ADB using the new instructions, and raise an issue if you encounter...an issue. :P S, ALR -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From alr at redhat.com Fri May 27 18:28:19 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Fri, 27 May 2016 14:28:19 -0400 Subject: [kontinuity-dev-public] Blue Ocean UI for Jenkins Message-ID: Announced today: https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/ S, ALR -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri May 27 18:29:51 2016 From: bparees at redhat.com (Ben Parees) Date: Fri, 27 May 2016 14:29:51 -0400 Subject: [kontinuity-dev-public] Blue Ocean UI for Jenkins In-Reply-To: References: Message-ID: excellent! On Fri, May 27, 2016 at 2:28 PM, Andrew Lee Rubinger wrote: > Announced today: > > https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/ > > S, > ALR > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From sspeiche at redhat.com Fri May 27 18:36:06 2016 From: sspeiche at redhat.com (Steve Speicher) Date: Fri, 27 May 2016 14:36:06 -0400 Subject: [kontinuity-dev-public] Blue Ocean UI for Jenkins In-Reply-To: References: Message-ID: What? An experience upgrade is needed for Jenkins ;)? This work looks great Thanks, Steve Speicher OpenShift by Red Hat On Fri, May 27, 2016 at 2:28 PM, Andrew Lee Rubinger wrote: > Announced today: > > https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/ > > S, > ALR > > -- > Red Hat Developer Programs Architecture > @ALRubinger > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnozicka at redhat.com Tue May 31 14:19:40 2016 From: tnozicka at redhat.com (Tomas Nozicka) Date: Tue, 31 May 2016 16:19:40 +0200 Subject: [kontinuity-dev-public] "Build slaves" in Jenkins pipelines Message-ID: <1464704380.9457.63.camel@redhat.com> Hi, how do we want to run our Jenkins "build slaves" in our pipelines? Options: 1) kubernetes plugin [1] = Example = node ('java8-maven') { ? sh 'mvn package' } = EOF = ?- tightly coupled to Jenkins instance (requires predefined pools of slaves which you can choose from) ?- build environment is defined by admin not pipeline (Jenkinsfile) ?- not generic 2) kubernetes-workflow plugin [2] = Example = kubernetes.pod('buildpod').withImage('java8-maven').inside{ ? sh 'mvn package' } =?EOF = ?+ loosely coupled to Jenkins instance ?+ pipeline (Jenkinsfile) specifies build environment ?+ generic (pipelines can specify custom?images) I am for option 2 because of the loose coupling to Jenkins and ability to specify (custom) build images as part of Jenkinsfile. And AFAIK catapult project is partially about taking user pipelines and setting those up with OpenShift(+Jenkins), I just don't see it working with the tight coupling and option 1. If we decide to go with option 2 we should probably integrate kubernetes-workflow plugin into jenkins-1-centos7:dev image. What do you think? Thanks, Tomas [1] -?https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin [2] -?https://github.com/fabric8io/kubernetes-workflow From jstracha at redhat.com Tue May 31 14:27:22 2016 From: jstracha at redhat.com (James Strachan) Date: Tue, 31 May 2016 15:27:22 +0100 Subject: [kontinuity-dev-public] "Build slaves" in Jenkins pipelines In-Reply-To: <1464704380.9457.63.camel@redhat.com> References: <1464704380.9457.63.camel@redhat.com> Message-ID: <98E99398-C5E5-4556-8C26-FB576253BF72@redhat.com> I?m a huge fan of 2); but currently that requires a pod for the JNLP slave and another pod for the docker image; which on premise or on Dedicated doesn?t really matter. But on OpenShift Online that is gonna be painful (3 pods just for builds!); so option 1) using one or two curated pools of slaves of custom pod/mages might be simpler for Online. e.g. one slave pool for maven/java and one for nodejs? > On 31 May 2016, at 15:19, Tomas Nozicka wrote: > > Hi, > > how do we want to run our Jenkins "build slaves" in our pipelines? > > Options: > 1) kubernetes plugin [1] > = Example = > node ('java8-maven') { > sh 'mvn package' > } > = EOF = > - tightly coupled to Jenkins instance (requires predefined pools of > slaves which you can choose from) > - build environment is defined by admin not pipeline (Jenkinsfile) > - not generic > > 2) kubernetes-workflow plugin [2] > = Example = > kubernetes.pod('buildpod').withImage('java8-maven').inside{ > sh 'mvn package' > } > = EOF = > + loosely coupled to Jenkins instance > + pipeline (Jenkinsfile) specifies build environment > + generic (pipelines can specify custom images) > > I am for option 2 because of the loose coupling to Jenkins and ability > to specify (custom) build images as part of Jenkinsfile. > > And AFAIK catapult project is partially about taking user pipelines and > setting those up with OpenShift(+Jenkins), I just don't see it working > with the tight coupling and option 1. > > If we decide to go with option 2 we should probably integrate > kubernetes-workflow plugin into jenkins-1-centos7:dev image. > > What do you think? > > Thanks, > Tomas > > [1] - https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin > [2] - https://github.com/fabric8io/kubernetes-workflow > > _______________________________________________ > kontinuity-dev-public mailing list > kontinuity-dev-public at redhat.com > https://www.redhat.com/mailman/listinfo/kontinuity-dev-public James ------- Red Hat Twitter: @jstrachan Email: jstracha at redhat.com Blog: https://medium.com/@jstrachan/ fabric8: http://fabric8.io/ open source microservices platform -------------- next part -------------- An HTML attachment was scrubbed... URL: