text:
'./kamel run xxx' and 'make test-integration' pod failures on Ubuntu 16.04 (with minikube)

SUMMARY
./kamel install brings up the camel-k-operator-xxx pod as expected.
# ./kamel install
Camel K installed in namespace default
# kubectl get pods -A
NAMESPACE     NAME                               READY   STATUS             RESTARTS   AGE
default       camel-k-operator-86cddf76d-qbttf   1/1     Running            0          5m12s

But when I execute ./kamel run examples/Sample.java:
# ./kamel run examples/Sample.java
integration "sample" created
# kubectl get pods -A
NAMESPACE     NAME                               READY   STATUS             RESTARTS   AGE
default       camel-k-operator-86cddf76d-qbttf   1/1     Running            0          5m12s
default       sample-7ddd4cf98d-smfgc            0/1     ImagePullBackOff   0          10s
...
# kubectl describe pod sample-7ddd4cf98d-smfgc
Name:         sample-7ddd4cf98d-smfgc
Namespace:    default
Priority:     0
Node:         x006vm57/129.40.81.57
Start Time:   Wed, 23 Dec 2020 03:24:58 -0500
Labels:       camel.apache.org/integration=sample
              pod-template-hash=7ddd4cf98d
Annotations:  <none>
Status:       Pending
IP:           172.17.0.6
IPs:
  IP:           172.17.0.6
Controlled By:  ReplicaSet/sample-7ddd4cf98d
Containers:
  integration:
    Container ID:
    Image:         10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
      -c
    Args:
      echo exec java -cp ./resources:/etc/camel/conf:/etc/camel/resources:/etc/camel/sources/i-source-000:dependencies/camel-k-integration-1.3.0-SNAPSHOT-runner.jar:dependencies/io.quarkus.arc.arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-bootstrap-runner-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-core-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-development-mode-spi-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-ide-launcher-1.8.0.Final.jar:dependencies/io.smallrye.common.smallrye-common-annotation-1.3.0.jar:dependencies/io.smallrye.common.smallrye-common-constraint-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-expression-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-function-1.1.0.jar:dependencies/io.smallrye.config.smallrye-config-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-common-1.8.6.jar:dependencies/jakarta.annotation.jakarta.annotation-api-1.3.5.jar:dependencies/jakarta.el.jakarta.el-api-3.0.3.jar:dependencies/jakarta.enterprise.jakarta.enterprise.cdi-api-2.0.2.jar:dependencies/jakarta.inject.jakarta.inject-api-1.0.jar:dependencies/jakarta.interceptor.jakarta.interceptor-api-1.2.5.jar:dependencies/jakarta.transaction.jakarta.transaction-api-1.3.3.jar:dependencies/org.apache.camel.camel-api-3.5.0.jar:dependencies/org.apache.camel.camel-base-3.5.0.jar:dependencies/org.apache.camel.camel-bean-3.5.0.jar:dependencies/org.apache.camel.camel-componentdsl-3.5.0.jar:dependencies/org.apache.camel.camel-core-catalog-3.5.0.jar:dependencies/org.apache.camel.camel-core-engine-3.5.0.jar:dependencies/org.apache.camel.camel-core-languages-3.5.0.jar:dependencies/org.apache.camel.camel-endpointdsl-3.5.0.jar:dependencies/org.apache.camel.camel-main-3.5.0.jar:dependencies/org.apache.camel.camel-management-api-3.5.0.jar:dependencies/org.apache.camel.camel-microprofile-config-3.5.0.jar:dependencies/org.apache.camel.camel-support-3.5.0.jar:dependencies/org.apache.camel.camel-timer-3.5.0.jar:dependencies/org.apache.camel.camel-tooling-model-3.5.0.jar:dependencies/org.apache.camel.camel-util-3.5.0.jar:dependencies/org.apache.camel.camel-util-json-3.5.0.jar:dependencies/org.apache.camel.k.camel-k-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-quarkus-1.5.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-bean-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-core-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-endpointdsl-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-main-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-common-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-timer-1.1.0.jar:dependencies/org.eclipse.microprofile.config.microprofile-config-api-1.4.jar:dependencies/org.eclipse.microprofile.context-propagation.microprofile-context-propagation-api-1.0.1.jar:dependencies/org.graalvm.sdk.graal-sdk-20.2.0.jar:dependencies/org.jboss.logging.jboss-logging-3.3.2.Final.jar:dependencies/org.jboss.logging.jboss-logging-annotations-2.1.0.Final.jar:dependencies/org.jboss.logmanager.jboss-logmanager-embedded-1.0.4.jar:dependencies/org.jboss.slf4j.slf4j-jboss-logging-1.2.0.Final.jar:dependencies/org.jboss.threads.jboss-threads-3.1.1.Final.jar:dependencies/org.jooq.joor-0.9.13.jar:dependencies/org.slf4j.slf4j-api-1.7.30.jar:dependencies/org.wildfly.common.wildfly-common-1.5.4.Final-format-001.jar io.quarkus.runner.GeneratedMain && exec java -cp ./resources:/etc/camel/conf:/etc/camel/resources:/etc/camel/sources/i-source-000:dependencies/camel-k-integration-1.3.0-SNAPSHOT-runner.jar:dependencies/io.quarkus.arc.arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-bootstrap-runner-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-core-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-development-mode-spi-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-ide-launcher-1.8.0.Final.jar:dependencies/io.smallrye.common.smallrye-common-annotation-1.3.0.jar:dependencies/io.smallrye.common.smallrye-common-constraint-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-expression-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-function-1.1.0.jar:dependencies/io.smallrye.config.smallrye-config-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-common-1.8.6.jar:dependencies/jakarta.annotation.jakarta.annotation-api-1.3.5.jar:dependencies/jakarta.el.jakarta.el-api-3.0.3.jar:dependencies/jakarta.enterprise.jakarta.enterprise.cdi-api-2.0.2.jar:dependencies/jakarta.inject.jakarta.inject-api-1.0.jar:dependencies/jakarta.interceptor.jakarta.interceptor-api-1.2.5.jar:dependencies/jakarta.transaction.jakarta.transaction-api-1.3.3.jar:dependencies/org.apache.camel.camel-api-3.5.0.jar:dependencies/org.apache.camel.camel-base-3.5.0.jar:dependencies/org.apache.camel.camel-bean-3.5.0.jar:dependencies/org.apache.camel.camel-componentdsl-3.5.0.jar:dependencies/org.apache.camel.camel-core-catalog-3.5.0.jar:dependencies/org.apache.camel.camel-core-engine-3.5.0.jar:dependencies/org.apache.camel.camel-core-languages-3.5.0.jar:dependencies/org.apache.camel.camel-endpointdsl-3.5.0.jar:dependencies/org.apache.camel.camel-main-3.5.0.jar:dependencies/org.apache.camel.camel-management-api-3.5.0.jar:dependencies/org.apache.camel.camel-microprofile-config-3.5.0.jar:dependencies/org.apache.camel.camel-support-3.5.0.jar:dependencies/org.apache.camel.camel-timer-3.5.0.jar:dependencies/org.apache.camel.camel-tooling-model-3.5.0.jar:dependencies/org.apache.camel.camel-util-3.5.0.jar:dependencies/org.apache.camel.camel-util-json-3.5.0.jar:dependencies/org.apache.camel.k.camel-k-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-quarkus-1.5.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-bean-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-core-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-endpointdsl-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-main-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-common-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-timer-1.1.0.jar:dependencies/org.eclipse.microprofile.config.microprofile-config-api-1.4.jar:dependencies/org.eclipse.microprofile.context-propagation.microprofile-context-propagation-api-1.0.1.jar:dependencies/org.graalvm.sdk.graal-sdk-20.2.0.jar:dependencies/org.jboss.logging.jboss-logging-3.3.2.Final.jar:dependencies/org.jboss.logging.jboss-logging-annotations-2.1.0.Final.jar:dependencies/org.jboss.logmanager.jboss-logmanager-embedded-1.0.4.jar:dependencies/org.jboss.slf4j.slf4j-jboss-logging-1.2.0.Final.jar:dependencies/org.jboss.threads.jboss-threads-3.1.1.Final.jar:dependencies/org.jooq.joor-0.9.13.jar:dependencies/org.slf4j.slf4j-api-1.7.30.jar:dependencies/org.wildfly.common.wildfly-common-1.5.4.Final-format-001.jar io.quarkus.runner.GeneratedMain
    State:          Waiting
      Reason:       ErrImagePull
    Ready:          False
    Restart Count:  0
    Environment:
      CAMEL_K_DIGEST:                 vZm-6F1eRDX8swCG_a79_AgSbB1iOkZ_s9KL2ZuTExMQ
      CAMEL_K_CONF:                   /etc/camel/conf/application.properties
      CAMEL_K_CONF_D:                 /etc/camel/conf.d
      CAMEL_K_VERSION:                1.3.0-SNAPSHOT
      CAMEL_K_INTEGRATION:            sample
      CAMEL_K_RUNTIME_VERSION:        1.5.0
      CAMEL_K_MOUNT_PATH_CONFIGMAPS:  /etc/camel/conf.d/_configmaps
      CAMEL_K_MOUNT_PATH_SECRETS:     /etc/camel/conf.d/_secrets
      NAMESPACE:                      default (v1:metadata.namespace)
      POD_NAME:                       sample-7ddd4cf98d-smfgc (v1:metadata.name)
    Mounts:
      /etc/camel/conf from application-properties (rw)
      /etc/camel/sources/i-source-000 from i-source-000 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-9h6gw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  i-source-000:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      sample-source-000
    Optional:  false
  application-properties:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      sample-application-properties
    Optional:  false
  default-token-9h6gw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-9h6gw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  109s                default-scheduler  Successfully assigned default/sample-7ddd4cf98d-smfgc to x006vm57
  Normal   BackOff    30s (x6 over 107s)  kubelet, x006vm57  Back-off pulling image "10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952"
  Normal   Pulling    19s (x4 over 108s)  kubelet, x006vm57  Pulling image "10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952"
  Warning  Failed     19s (x4 over 108s)  kubelet, x006vm57  Failed to pull image "10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952": rpc error: code = Unknown desc = Error response from daemon: Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused
  Warning  Failed     19s (x4 over 108s)  kubelet, x006vm57  Error: ErrImagePull
  Warning  Failed     5s (x7 over 107s)   kubelet, x006vm57  Error: ImagePullBackOff

Similar issue is seen with make test-integration. Most of the tests fail with a timeout because of being unable to bring up the pods:
# make test-integration
...
STAGING_RUNTIME_REPO="" go test -timeout 60m -v ./e2e/common -tags=integration && go test -timeout 60m -v ./e2e/common/languages -tags=integration
=== RUN   TestAddons
Camel K installed in namespace test-efc69ac8-14d7-4307-a875-cb925be209c3
=== RUN   TestAddons/master_works
integration "master" created
    addons_test.go:40:
        Timed out after 300.004s.
        Expected
            <v1.PodPhase>: Pending
        to equal
            <v1.PodPhase>: Running
...
# kubectl get pods -A
...
test-efc69ac8-14d7-4307-a875-cb925be209c3   camel-k-operator-86cddf76d-ns2gm   1/1     Running        0          71s
test-efc69ac8-14d7-4307-a875-cb925be209c3   master-844f5f686b-gpkld            0/1     ErrImagePull   0          42s
# kubectl describe pod master-844f5f686b-gpkld -n test-efc69ac8-14d7-4307-a875-cb925be209c3
Name:         master-844f5f686b-gpkld
Namespace:    test-efc69ac8-14d7-4307-a875-cb925be209c3
Priority:     0
Node:         x006vm57/129.40.81.57
Start Time:   Wed, 23 Dec 2020 03:45:35 -0500
Labels:       camel.apache.org/integration=master
              pod-template-hash=844f5f686b
Annotations:  <none>
Status:       Pending
IP:           172.17.0.6
IPs:
  IP:           172.17.0.6
Controlled By:  ReplicaSet/master-844f5f686b
Containers:
  integration:
    Container ID:
    Image:         10.106.145.48/test-efc69ac8-14d7-4307-a875-cb925be209c3/camel-k-kit-bvhg75j73ovr2elqih80@sha256:28083a9308f2a51ca771dd28034ad19f560e31e86024c307690156440089d731
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
      -c
    Args:
      echo exec java -cp ./resources:/etc/camel/conf:/etc/camel/conf.d:/etc/camel/resources:/etc/camel/sources/i-source-000:dependencies/camel-k-integration-1.3.0-SNAPSHOT-runner.jar:dependencies/com.fasterxml.jackson.core.jackson-annotations-2.11.2.jar:dependencies/com.fasterxml.jackson.core.jackson-core-2.11.2.jar:dependencies/com.fasterxml.jackson.core.jackson-databind-2.11.2.jar:dependencies/com.fasterxml.jackson.dataformat.jackson-dataformat-yaml-2.11.2.jar:dependencies/com.fasterxml.jackson.datatype.jackson-datatype-jdk8-2.11.2.jar:dependencies/com.fasterxml.jackson.datatype.jackson-datatype-jsr310-2.11.2.jar:dependencies/com.fasterxml.jackson.module.jackson-module-jaxb-annotations-2.11.2.jar:dependencies/com.fasterxml.jackson.module.jackson-module-parameter-names-2.11.2.jar:dependencies/com.github.mifmif.generex-1.0.2.jar:dependencies/com.squareup.okhttp3.logging-interceptor-3.14.6.jar:dependencies/com.squareup.okhttp3.okhttp-3.14.6.jar:dependencies/com.squareup.okio.okio-1.17.2.jar:dependencies/dk.brics.automaton.automaton-1.11-8.jar:dependencies/io.fabric8.kubernetes-client-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-admissionregistration-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-apiextensions-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-apps-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-autoscaling-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-batch-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-certificates-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-common-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-coordination-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-core-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-discovery-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-events-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-extensions-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-metrics-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-networking-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-policy-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-rbac-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-scheduling-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-settings-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-storageclass-4.10.3.jar:dependencies/io.fabric8.openshift-client-4.10.3.jar:dependencies/io.fabric8.openshift-model-4.10.3.jar:dependencies/io.fabric8.zjsonpatch-0.3.0.jar:dependencies/io.quarkus.arc.arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-bootstrap-runner-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-core-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-development-mode-spi-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-ide-launcher-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-jackson-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-kubernetes-client-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-kubernetes-client-internal-1.8.0.Final.jar:dependencies/io.smallrye.common.smallrye-common-annotation-1.3.0.jar:dependencies/io.smallrye.common.smallrye-common-constraint-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-expression-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-function-1.1.0.jar:dependencies/io.smallrye.config.smallrye-config-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-common-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-source-yaml-1.8.6.jar:dependencies/jakarta.activation.jakarta.activation-api-1.2.1.jar:dependencies/jakarta.annotation.jakarta.annotation-api-1.3.5.jar:dependencies/jakarta.el.jakarta.el-api-3.0.3.jar:dependencies/jakarta.enterprise.jakarta.enterprise.cdi-api-2.0.2.jar:dependencies/jakarta.inject.jakarta.inject-api-1.0.jar:dependencies/jakarta.interceptor.jakarta.interceptor-api-1.2.5.jar:dependencies/jakarta.transaction.jakarta.transaction-api-1.3.3.jar:dependencies/org.apache.camel.camel-api-3.5.0.jar:dependencies/org.apache.camel.camel-base-3.5.0.jar:dependencies/org.apache.camel.camel-bean-3.5.0.jar:dependencies/org.apache.camel.camel-cloud-3.5.0.jar:dependencies/org.apache.camel.camel-cluster-3.5.0.jar:dependencies/org.apache.camel.camel-componentdsl-3.5.0.jar:dependencies/org.apache.camel.camel-core-catalog-3.5.0.jar:dependencies/org.apache.camel.camel-core-engine-3.5.0.jar:dependencies/org.apache.camel.camel-core-languages-3.5.0.jar:dependencies/org.apache.camel.camel-endpointdsl-3.5.0.jar:dependencies/org.apache.camel.camel-kubernetes-3.5.0.jar:dependencies/org.apache.camel.camel-main-3.5.0.jar:dependencies/org.apache.camel.camel-management-api-3.5.0.jar:dependencies/org.apache.camel.camel-master-3.5.0.jar:dependencies/org.apache.camel.camel-microprofile-config-3.5.0.jar:dependencies/org.apache.camel.camel-support-3.5.0.jar:dependencies/org.apache.camel.camel-timer-3.5.0.jar:dependencies/org.apache.camel.camel-tooling-model-3.5.0.jar:dependencies/org.apache.camel.camel-util-3.5.0.jar:dependencies/org.apache.camel.camel-util-json-3.5.0.jar:dependencies/org.apache.camel.k.camel-k-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-master-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-master-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-quarkus-1.5.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-bean-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-core-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-endpointdsl-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-kubernetes-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-main-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-master-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-common-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-commons-logging-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-timer-1.1.0.jar:dependencies/org.apache.commons.commons-compress-1.20.jar:dependencies/org.eclipse.microprofile.config.microprofile-config-api-1.4.jar:dependencies/org.eclipse.microprofile.context-propagation.microprofile-context-propagation-api-1.0.1.jar:dependencies/org.graalvm.sdk.graal-sdk-20.2.0.jar:dependencies/org.jboss.logging.commons-logging-jboss-logging-1.0.0.Final.jar:dependencies/org.jboss.logging.jboss-logging-3.3.2.Final.jar:dependencies/org.jboss.logging.jboss-logging-annotations-2.1.0.Final.jar:dependencies/org.jboss.logmanager.jboss-logmanager-embedded-1.0.4.jar:dependencies/org.jboss.slf4j.slf4j-jboss-logging-1.2.0.Final.jar:dependencies/org.jboss.spec.javax.xml.bind.jboss-jaxb-api_2.3_spec-2.0.0.Final.jar:dependencies/org.jboss.threads.jboss-threads-3.1.1.Final.jar:dependencies/org.jooq.joor-0.9.13.jar:dependencies/org.slf4j.slf4j-api-1.7.30.jar:dependencies/org.wildfly.common.wildfly-common-1.5.4.Final-format-001.jar:dependencies/org.yaml.snakeyaml-1.26.jar io.quarkus.runner.GeneratedMain && exec java -cp ./resources:/etc/camel/conf:/etc/camel/conf.d:/etc/camel/resources:/etc/camel/sources/i-source-000:dependencies/camel-k-integration-1.3.0-SNAPSHOT-runner.jar:dependencies/com.fasterxml.jackson.core.jackson-annotations-2.11.2.jar:dependencies/com.fasterxml.jackson.core.jackson-core-2.11.2.jar:dependencies/com.fasterxml.jackson.core.jackson-databind-2.11.2.jar:dependencies/com.fasterxml.jackson.dataformat.jackson-dataformat-yaml-2.11.2.jar:dependencies/com.fasterxml.jackson.datatype.jackson-datatype-jdk8-2.11.2.jar:dependencies/com.fasterxml.jackson.datatype.jackson-datatype-jsr310-2.11.2.jar:dependencies/com.fasterxml.jackson.module.jackson-module-jaxb-annotations-2.11.2.jar:dependencies/com.fasterxml.jackson.module.jackson-module-parameter-names-2.11.2.jar:dependencies/com.github.mifmif.generex-1.0.2.jar:dependencies/com.squareup.okhttp3.logging-interceptor-3.14.6.jar:dependencies/com.squareup.okhttp3.okhttp-3.14.6.jar:dependencies/com.squareup.okio.okio-1.17.2.jar:dependencies/dk.brics.automaton.automaton-1.11-8.jar:dependencies/io.fabric8.kubernetes-client-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-admissionregistration-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-apiextensions-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-apps-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-autoscaling-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-batch-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-certificates-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-common-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-coordination-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-core-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-discovery-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-events-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-extensions-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-metrics-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-networking-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-policy-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-rbac-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-scheduling-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-settings-4.10.3.jar:dependencies/io.fabric8.kubernetes-model-storageclass-4.10.3.jar:dependencies/io.fabric8.openshift-client-4.10.3.jar:dependencies/io.fabric8.openshift-model-4.10.3.jar:dependencies/io.fabric8.zjsonpatch-0.3.0.jar:dependencies/io.quarkus.arc.arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-arc-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-bootstrap-runner-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-core-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-development-mode-spi-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-ide-launcher-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-jackson-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-kubernetes-client-1.8.0.Final.jar:dependencies/io.quarkus.quarkus-kubernetes-client-internal-1.8.0.Final.jar:dependencies/io.smallrye.common.smallrye-common-annotation-1.3.0.jar:dependencies/io.smallrye.common.smallrye-common-constraint-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-expression-1.1.0.jar:dependencies/io.smallrye.common.smallrye-common-function-1.1.0.jar:dependencies/io.smallrye.config.smallrye-config-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-common-1.8.6.jar:dependencies/io.smallrye.config.smallrye-config-source-yaml-1.8.6.jar:dependencies/jakarta.activation.jakarta.activation-api-1.2.1.jar:dependencies/jakarta.annotation.jakarta.annotation-api-1.3.5.jar:dependencies/jakarta.el.jakarta.el-api-3.0.3.jar:dependencies/jakarta.enterprise.jakarta.enterprise.cdi-api-2.0.2.jar:dependencies/jakarta.inject.jakarta.inject-api-1.0.jar:dependencies/jakarta.interceptor.jakarta.interceptor-api-1.2.5.jar:dependencies/jakarta.transaction.jakarta.transaction-api-1.3.3.jar:dependencies/org.apache.camel.camel-api-3.5.0.jar:dependencies/org.apache.camel.camel-base-3.5.0.jar:dependencies/org.apache.camel.camel-bean-3.5.0.jar:dependencies/org.apache.camel.camel-cloud-3.5.0.jar:dependencies/org.apache.camel.camel-cluster-3.5.0.jar:dependencies/org.apache.camel.camel-componentdsl-3.5.0.jar:dependencies/org.apache.camel.camel-core-catalog-3.5.0.jar:dependencies/org.apache.camel.camel-core-engine-3.5.0.jar:dependencies/org.apache.camel.camel-core-languages-3.5.0.jar:dependencies/org.apache.camel.camel-endpointdsl-3.5.0.jar:dependencies/org.apache.camel.camel-kubernetes-3.5.0.jar:dependencies/org.apache.camel.camel-main-3.5.0.jar:dependencies/org.apache.camel.camel-management-api-3.5.0.jar:dependencies/org.apache.camel.camel-master-3.5.0.jar:dependencies/org.apache.camel.camel-microprofile-config-3.5.0.jar:dependencies/org.apache.camel.camel-support-3.5.0.jar:dependencies/org.apache.camel.camel-timer-3.5.0.jar:dependencies/org.apache.camel.camel-tooling-model-3.5.0.jar:dependencies/org.apache.camel.camel-util-3.5.0.jar:dependencies/org.apache.camel.camel-util-json-3.5.0.jar:dependencies/org.apache.camel.k.camel-k-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-loader-java-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-quarkus-master-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-core-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-master-1.5.0.jar:dependencies/org.apache.camel.k.camel-k-runtime-quarkus-1.5.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-bean-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-core-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-endpointdsl-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-kubernetes-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-main-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-master-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-common-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-support-commons-logging-1.1.0.jar:dependencies/org.apache.camel.quarkus.camel-quarkus-timer-1.1.0.jar:dependencies/org.apache.commons.commons-compress-1.20.jar:dependencies/org.eclipse.microprofile.config.microprofile-config-api-1.4.jar:dependencies/org.eclipse.microprofile.context-propagation.microprofile-context-propagation-api-1.0.1.jar:dependencies/org.graalvm.sdk.graal-sdk-20.2.0.jar:dependencies/org.jboss.logging.commons-logging-jboss-logging-1.0.0.Final.jar:dependencies/org.jboss.logging.jboss-logging-3.3.2.Final.jar:dependencies/org.jboss.logging.jboss-logging-annotations-2.1.0.Final.jar:dependencies/org.jboss.logmanager.jboss-logmanager-embedded-1.0.4.jar:dependencies/org.jboss.slf4j.slf4j-jboss-logging-1.2.0.Final.jar:dependencies/org.jboss.spec.javax.xml.bind.jboss-jaxb-api_2.3_spec-2.0.0.Final.jar:dependencies/org.jboss.threads.jboss-threads-3.1.1.Final.jar:dependencies/org.jooq.joor-0.9.13.jar:dependencies/org.slf4j.slf4j-api-1.7.30.jar:dependencies/org.wildfly.common.wildfly-common-1.5.4.Final-format-001.jar:dependencies/org.yaml.snakeyaml-1.26.jar io.quarkus.runner.GeneratedMain
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Environment:
      CAMEL_K_DIGEST:                 vXeVlgXuLwlvwxkG3cfb1DX9bw2gBeaVaoQGdmZAeG40
      CAMEL_K_CONF:                   /etc/camel/conf/application.properties
      CAMEL_K_CONF_D:                 /etc/camel/conf.d
      CAMEL_K_VERSION:                1.3.0-SNAPSHOT
      CAMEL_K_INTEGRATION:            master
      CAMEL_K_RUNTIME_VERSION:        1.5.0
      CAMEL_K_MOUNT_PATH_CONFIGMAPS:  /etc/camel/conf.d/_configmaps
      CAMEL_K_MOUNT_PATH_SECRETS:     /etc/camel/conf.d/_secrets
      NAMESPACE:                      test-efc69ac8-14d7-4307-a875-cb925be209c3 (v1:metadata.namespace)
      POD_NAME:                       master-844f5f686b-gpkld (v1:metadata.name)
    Mounts:
      /etc/camel/conf from application-properties (rw)
      /etc/camel/conf.d from user-properties (rw)
      /etc/camel/sources/i-source-000 from i-source-000 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-nzbjw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  i-source-000:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      master-source-000
    Optional:  false
  user-properties:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      master-user-properties
    Optional:  false
  application-properties:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      master-application-properties
    Optional:  false
  default-token-nzbjw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-nzbjw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  93s                default-scheduler  Successfully assigned test-efc69ac8-14d7-4307-a875-cb925be209c3/master-844f5f686b-gpkld to x006vm57
  Normal   Pulling    50s (x3 over 93s)  kubelet, x006vm57  Pulling image "10.106.145.48/test-efc69ac8-14d7-4307-a875-cb925be209c3/camel-k-kit-bvhg75j73ovr2elqih80@sha256:28083a9308f2a51ca771dd28034ad19f560e31e86024c307690156440089d731"
  Warning  Failed     50s (x3 over 93s)  kubelet, x006vm57  Failed to pull image "10.106.145.48/test-efc69ac8-14d7-4307-a875-cb925be209c3/camel-k-kit-bvhg75j73ovr2elqih80@sha256:28083a9308f2a51ca771dd28034ad19f560e31e86024c307690156440089d731": rpc error: code = Unknown desc = Error response from daemon: Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused
  Warning  Failed     50s (x3 over 93s)  kubelet, x006vm57  Error: ErrImagePull
  Normal   BackOff    11s (x5 over 92s)  kubelet, x006vm57  Back-off pulling image "10.106.145.48/test-efc69ac8-14d7-4307-a875-cb925be209c3/camel-k-kit-bvhg75j73ovr2elqih80@sha256:28083a9308f2a51ca771dd28034ad19f560e31e86024c307690156440089d731"
  Warning  Failed     11s (x5 over 92s)  kubelet, x006vm57  Error: ImagePullBackOff

camel-k VERSION
Camel K Client 1.3.0-SNAPSHOT
commit: a4df39bb039f62b023b166970a1a67e1965cf9f3
OS, environment
Ubuntu 16.04.7 LTS (Xenial Xerus) amd64
Steps to reproduce the problem
add-apt-repository ppa:openjdk-r/ppa
apt-get update
apt-get install -y openjdk-11-jdk
apt-get install -y make git wget gcc
JDK_PATHS=$(compgen -G '/usr/lib/jvm/java-11-openjdk-*')
export JAVA_HOME=${JDK_PATHS%$'\n'*}
export PATH=$JAVA_HOME/bin:$PATH

wget https://golang.org/dl/go1.15.2.linux-amd64.tar.gz
tar -xzf go1.15.2.linux-amd64.tar.gz
rm -rf go1.15.2.linux-amd64.tar.gz
export GOPATH=`pwd`/gopath
export PATH=`pwd`/go/bin:$GOPATH/bin:$PATH
mkdir -p $GOPATH/src/github.com/apache
cd $GOPATH/src/github.com/apache
git clone https://github.com/apache/camel-k.git
cd camel-k/
make test
make package-artifacts
make images
minikube start --driver=none
minikube addons enable registry

./kamel install
./kamel run examples/Sample.java

OR
make test-integration

Expected Results
sample-xxx pod should come up without (ImagePullBackOff) issues on command ./kamel run examples/Sample.java.
make test-integration should not exhibit the timeout issues due to ImagePullBackOff errors in pods.
Please help me resolve these issues. Thanks!

It appears you have to run make install-minikube first. What happens if you do it?

Even with that, I see the same issue. It gets the camel-k-operator-xx pod up, but ./kamel run examples/Sample.java fails to bring the sample-xxx pod up.

@astefanutti can you provide any pointers for this?

@astefanutti can you provide any pointers for this?

@amitsadaphule for some reasons, the integration pod fails to pull the container image that has been built for that integration:
 Failed to pull image "10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952": rpc error: code = Unknown desc = Error response from daemon: Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused

What cluster do you use, and how did you configure the container registry?
Also dumping the IntegrationPlatform may help, e.g., kubectl get ip camel-k -o yaml.

@amitsadaphule for some reasons, the integration pod fails to pull the container image that has been built for that integration:
 Failed to pull image "10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g@sha256:93289fd05071c295ce83d796cc1e42c767fd18b34ba569f871746af472afe952": rpc error: code = Unknown desc = Error response from daemon: Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused

What cluster do you use, and how did you configure the container registry?
Also dumping the IntegrationPlatform may help, e.g., kubectl get ip camel-k -o yaml.

Thanks for the reply @astefanutti ! I'm using minikube and here's how I setup the registry:

Built gcr.io/google_containers/kube-registry-proxy:0.4 image from source https://github.com/povilasv/kube-registry-proxy.git
Built registry binary from source https://github.com/docker/distribution-library-image.git
Built registry.hub.docker.com/library/registry:2.7.1 image from source https://github.com/docker/distribution-library-image.git by copying the registry binary built in step #2 to distribution-library-image directory
Executed minikube addons enable registry

Post that I was able to see the registry pods coming up:
# kubectl get pods -A
NAMESPACE     NAME                                READY   STATUS             RESTARTS   AGE
default       camel-k-operator-57bbcbd6dc-j5kcv   1/1     Running            0          154m
default       sample-5bc495b9cb-rbbzm             0/1     ImagePullBackOff   0          151m
kube-system   coredns-f9fd979d6-7678j             1/1     Running            6          10d
kube-system   etcd-p006vm87                       1/1     Running            12         10d
kube-system   kube-apiserver-p006vm87             1/1     Running            14         10d
kube-system   kube-controller-manager-p006vm87    1/1     Running            9          10d
kube-system   kube-proxy-q7pfw                    1/1     Running            6          10d
kube-system   kube-scheduler-p006vm87             1/1     Running            6          10d
kube-system   registry-8d28l                      1/1     Running            3          2d15h
kube-system   registry-proxy-q26fb                1/1     Running            3          2d15h

Also, here's the output of kubectl get ip camel-k -o yaml
# kubectl get ip camel-k -o yaml
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
  creationTimestamp: "2021-01-22T10:11:08Z"
  generation: 1
  labels:
    app: camel-k
  managedFields:
  - apiVersion: camel.apache.org/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
      f:spec:
        .: {}
        f:build:
          .: {}
          f:maven:
            .: {}
            f:settings: {}
          f:publishStrategy: {}
          f:registry:
            .: {}
            f:address: {}
            f:insecure: {}
        f:kamelet: {}
        f:resources: {}
      f:status:
        .: {}
        f:build:
          .: {}
          f:baseImage: {}
          f:buildStrategy: {}
          f:maven:
            .: {}
            f:localRepository: {}
            f:settings:
              .: {}
              f:configMapKeyRef:
                .: {}
                f:key: {}
                f:name: {}
            f:timeout: {}
          f:persistentVolumeClaim: {}
          f:publishStrategy: {}
          f:registry:
            .: {}
            f:address: {}
            f:insecure: {}
          f:runtimeVersion: {}
          f:timeout: {}
        f:cluster: {}
        f:kamelet:
          .: {}
          f:repositories: {}
        f:phase: {}
        f:resources: {}
        f:version: {}
    manager: kamel
    operation: Update
    time: "2021-01-22T10:11:17Z"
  name: camel-k
  namespace: default
  resourceVersion: "703539"
  selfLink: /apis/camel.apache.org/v1/namespaces/default/integrationplatforms/camel-k
  uid: 74046037-87a3-4c9f-bd12-40af390713c7
spec:
  build:
    maven:
      settings: {}
    publishStrategy: Spectrum
    registry:
      address: 10.103.184.236
      insecure: true
  kamelet: {}
  resources: {}
status:
  build:
    baseImage: adoptopenjdk/openjdk11:ubi
    buildStrategy: routine
    maven:
      localRepository: /tmp/artifacts/m2
      settings:
        configMapKeyRef:
          key: settings.xml
          name: camel-k-maven-settings
      timeout: 3m45s
    persistentVolumeClaim: camel-k
    publishStrategy: Spectrum
    registry:
      address: 10.103.184.236
      insecure: true
    runtimeVersion: 1.6.0
    timeout: 5m0s
  cluster: Kubernetes
  kamelet:
    repositories:
    - uri: github:apache/camel-kamelets
  phase: Ready
  version: 1.3.0

Thanks for the reply @astefanutti ! I'm using minikube and here's how I setup the registry:

Built gcr.io/google_containers/kube-registry-proxy:0.4 image from source https://github.com/povilasv/kube-registry-proxy.git
Built registry binary from source https://github.com/docker/distribution-library-image.git
Built registry.hub.docker.com/library/registry:2.7.1 image from source https://github.com/docker/distribution-library-image.git by copying the registry binary built in step #2 to distribution-library-image directory
Executed minikube addons enable registry

Post that I was able to see the registry pods coming up:
# kubectl get pods -A
NAMESPACE     NAME                                READY   STATUS             RESTARTS   AGE
default       camel-k-operator-57bbcbd6dc-j5kcv   1/1     Running            0          154m
default       sample-5bc495b9cb-rbbzm             0/1     ImagePullBackOff   0          151m
kube-system   coredns-f9fd979d6-7678j             1/1     Running            6          10d
kube-system   etcd-p006vm87                       1/1     Running            12         10d
kube-system   kube-apiserver-p006vm87             1/1     Running            14         10d
kube-system   kube-controller-manager-p006vm87    1/1     Running            9          10d
kube-system   kube-proxy-q7pfw                    1/1     Running            6          10d
kube-system   kube-scheduler-p006vm87             1/1     Running            6          10d
kube-system   registry-8d28l                      1/1     Running            3          2d15h
kube-system   registry-proxy-q26fb                1/1     Running            3          2d15h

Also, here's the output of kubectl get ip camel-k -o yaml
# kubectl get ip camel-k -o yaml
apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
  creationTimestamp: "2021-01-22T10:11:08Z"
  generation: 1
  labels:
    app: camel-k
  managedFields:
  - apiVersion: camel.apache.org/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
      f:spec:
        .: {}
        f:build:
          .: {}
          f:maven:
            .: {}
            f:settings: {}
          f:publishStrategy: {}
          f:registry:
            .: {}
            f:address: {}
            f:insecure: {}
        f:kamelet: {}
        f:resources: {}
      f:status:
        .: {}
        f:build:
          .: {}
          f:baseImage: {}
          f:buildStrategy: {}
          f:maven:
            .: {}
            f:localRepository: {}
            f:settings:
              .: {}
              f:configMapKeyRef:
                .: {}
                f:key: {}
                f:name: {}
            f:timeout: {}
          f:persistentVolumeClaim: {}
          f:publishStrategy: {}
          f:registry:
            .: {}
            f:address: {}
            f:insecure: {}
          f:runtimeVersion: {}
          f:timeout: {}
        f:cluster: {}
        f:kamelet:
          .: {}
          f:repositories: {}
        f:phase: {}
        f:resources: {}
        f:version: {}
    manager: kamel
    operation: Update
    time: "2021-01-22T10:11:17Z"
  name: camel-k
  namespace: default
  resourceVersion: "703539"
  selfLink: /apis/camel.apache.org/v1/namespaces/default/integrationplatforms/camel-k
  uid: 74046037-87a3-4c9f-bd12-40af390713c7
spec:
  build:
    maven:
      settings: {}
    publishStrategy: Spectrum
    registry:
      address: 10.103.184.236
      insecure: true
  kamelet: {}
  resources: {}
status:
  build:
    baseImage: adoptopenjdk/openjdk11:ubi
    buildStrategy: routine
    maven:
      localRepository: /tmp/artifacts/m2
      settings:
        configMapKeyRef:
          key: settings.xml
          name: camel-k-maven-settings
      timeout: 3m45s
    persistentVolumeClaim: camel-k
    publishStrategy: Spectrum
    registry:
      address: 10.103.184.236
      insecure: true
    runtimeVersion: 1.6.0
    timeout: 5m0s
  cluster: Kubernetes
  kamelet:
    repositories:
    - uri: github:apache/camel-kamelets
  phase: Ready
  version: 1.3.0

Thanks, I'm surprised that the IntegrationPlatform has:
status:
  build:
    registry:
      address: 10.103.184.236

While the Integration pod tries to pull the image from 10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g....
My understanding is that the IP addresses should match. It seems 10.103.184.236 is the correct one as the operator has been able to push the image, and that 10.106.145.48 is not correct. Though it is supposed to be the same.
I would try to check which IP address can be used to reach the registry. Then I would try to delete all the IntegrationKit and Integration resources:
$ kubectl delete ik,it --all

Then re-create the Integration, so that it creates a fresh new container image build.

Thanks, I'm surprised that the IntegrationPlatform has:
status:
  build:
    registry:
      address: 10.103.184.236

While the Integration pod tries to pull the image from 10.106.145.48/default/camel-k-kit-bvhfthd6er6mi7d78k6g....
My understanding is that the IP addresses should match. It seems 10.103.184.236 is the correct one as the operator has been able to push the image, and that 10.106.145.48 is not correct. Though it is supposed to be the same.
I would try to check which IP address can be used to reach the registry. Then I would try to delete all the IntegrationKit and Integration resources:
$ kubectl delete ik,it --all

Then re-create the Integration, so that it creates a fresh new container image build.

@astefanutti sorry about the mixed up logs. The one from kubectl get ip camel-k -o yaml that I posted above is from a different VM altogether. And the pod description there matches the IP:
Events:
  Type     Reason   Age                      From     Message
  ----     ------   ----                     ----     -------
  Normal   BackOff  9m38s (x1055 over 4h9m)  kubelet  Back-off pulling image "10.103.184.236/default/camel-k-kit-c03kvrjdiqnieco98l2g@sha256:5938d9b4fc02824a622db92ab3650685a0e53c6faa8c82d2e14a72442e00ab5e"
  Warning  Failed   4m40s (x1077 over 4h9m)  kubelet  Error: ImagePullBackOff

I'll still try executing kubectl delete ik,it --all and re-creating the build.

@astefanutti sorry about the mixed up logs. The one from kubectl get ip camel-k -o yaml that I posted above is from a different VM altogether. And the pod description there matches the IP:
Events:
  Type     Reason   Age                      From     Message
  ----     ------   ----                     ----     -------
  Normal   BackOff  9m38s (x1055 over 4h9m)  kubelet  Back-off pulling image "10.103.184.236/default/camel-k-kit-c03kvrjdiqnieco98l2g@sha256:5938d9b4fc02824a622db92ab3650685a0e53c6faa8c82d2e14a72442e00ab5e"
  Warning  Failed   4m40s (x1077 over 4h9m)  kubelet  Error: ImagePullBackOff

I'll still try executing kubectl delete ik,it --all and re-creating the build.

Same issue even after deleting ik, it and re-executing ./kamel run examples/Sample.java.
# kubectl get all -n default
NAME                                    READY   STATUS             RESTARTS   AGE
pod/camel-k-operator-57bbcbd6dc-j5kcv   1/1     Running            0          4h28m
pod/sample-95d958b69-z556d              0/1     ImagePullBackOff   0          55s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   10d

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/camel-k-operator   1/1     1            1           4h28m
deployment.apps/sample             0/1     1            0           56s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/camel-k-operator-57bbcbd6dc   1         1         1       4h28m
replicaset.apps/sample-95d958b69              1         1         0       56s

# kubectl get ik,it -A
NAMESPACE   NAME                                                       PHASE   TYPE       IMAGE
default     integrationkit.camel.apache.org/kit-c05e6g5f57dq9p35q41g   Ready   platform   10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200

NAMESPACE   NAME                                  PHASE     KIT                        REPLICAS
default     integration.camel.apache.org/sample   Running   kit-c05e6g5f57dq9p35q41g   1

# kubectl describe pod sample-95d958b69-z556d -n default
...
...
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  2m22s                default-scheduler  Successfully assigned default/sample-95d958b69-z556d to p006vm87
  Normal   Pulling    55s (x4 over 2m18s)  kubelet            Pulling image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200"
  Warning  Failed     55s (x4 over 2m18s)  kubelet            Failed to pull image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200": rpc error: code = Unknown desc = Error response from daemon: Get https://10.103.184.236/v2/: dial tcp 10.103.184.236:443: connect: connection refused
  Warning  Failed     55s (x4 over 2m18s)  kubelet            Error: ErrImagePull
  Normal   BackOff    44s (x6 over 2m17s)  kubelet            Back-off pulling image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200"
  Warning  Failed     29s (x7 over 2m17s)  kubelet            Error: ImagePullBackOff

Same issue even after deleting ik, it and re-executing ./kamel run examples/Sample.java.
# kubectl get all -n default
NAME                                    READY   STATUS             RESTARTS   AGE
pod/camel-k-operator-57bbcbd6dc-j5kcv   1/1     Running            0          4h28m
pod/sample-95d958b69-z556d              0/1     ImagePullBackOff   0          55s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   10d

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/camel-k-operator   1/1     1            1           4h28m
deployment.apps/sample             0/1     1            0           56s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/camel-k-operator-57bbcbd6dc   1         1         1       4h28m
replicaset.apps/sample-95d958b69              1         1         0       56s

# kubectl get ik,it -A
NAMESPACE   NAME                                                       PHASE   TYPE       IMAGE
default     integrationkit.camel.apache.org/kit-c05e6g5f57dq9p35q41g   Ready   platform   10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200

NAMESPACE   NAME                                  PHASE     KIT                        REPLICAS
default     integration.camel.apache.org/sample   Running   kit-c05e6g5f57dq9p35q41g   1

# kubectl describe pod sample-95d958b69-z556d -n default
...
...
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  2m22s                default-scheduler  Successfully assigned default/sample-95d958b69-z556d to p006vm87
  Normal   Pulling    55s (x4 over 2m18s)  kubelet            Pulling image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200"
  Warning  Failed     55s (x4 over 2m18s)  kubelet            Failed to pull image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200": rpc error: code = Unknown desc = Error response from daemon: Get https://10.103.184.236/v2/: dial tcp 10.103.184.236:443: connect: connection refused
  Warning  Failed     55s (x4 over 2m18s)  kubelet            Error: ErrImagePull
  Normal   BackOff    44s (x6 over 2m17s)  kubelet            Back-off pulling image "10.103.184.236/default/camel-k-kit-c05e6g5f57dq9p35q41g@sha256:bb486d97a46e7d45e55497c99d01d869bfb1c71023220dda2c7d1343ed6bc200"
  Warning  Failed     29s (x7 over 2m17s)  kubelet            Error: ImagePullBackOff

No worries, so now that we are sure the IP matches, we need to understand:
Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused

I'm surprised it uses HTTPS as the registry is configured as insecure. I'd have a look at the registry deployment and understand why the kubelet tries to pull the image using HTTPS.

No worries, so now that we are sure the IP matches, we need to understand:
Get https://10.106.145.48/v2/: dial tcp 10.106.145.48:443: connect: connection refused

I'm surprised it uses HTTPS as the registry is configured as insecure. I'd have a look at the registry deployment and understand why the kubelet tries to pull the image using HTTPS.

Thanks @astefanutti for the support! I'll try to check from my side too.

Thanks @astefanutti for the support! I'll try to check from my side too.

@amitsadaphule maybe this can help: https://minikube.sigs.k8s.io/docs/handbook/registry/#enabling-insecure-registries.

One nifty hack is to allow the kubelet running in minikube to talk to registries deployed inside a pod in the cluster without backing them with TLS certificates. Because the default service cluster IP is known to be available at 10.0.0.1, users can pull images from registries deployed inside the cluster by creating the cluster with minikube start --insecure-registry "10.0.0.0/24".

@amitsadaphule maybe this can help: https://minikube.sigs.k8s.io/docs/handbook/registry/#enabling-insecure-registries.

One nifty hack is to allow the kubelet running in minikube to talk to registries deployed inside a pod in the cluster without backing them with TLS certificates. Because the default service cluster IP is known to be available at 10.0.0.1, users can pull images from registries deployed inside the cluster by creating the cluster with minikube start --insecure-registry "10.0.0.0/24".

Thanks  @astefanutti ! Got your comment from the other issue earlier :) Unfortunately, I've not been able to get that to work yet. Tried passing the flag to the minikube start command minikube start --driver=none --insecure-registry "10.0.0.0/24", but that does not enable the registry pods which cases the ./kamel install command to fail with error:
# ./kamel install
Error: cannot find automatically a registry where to push images

So, I executed minikube addons enable registry which started the registry and registry proxy pods, but resulted in the same error as before Unknown desc = Error response from daemon: Get https://<SOMEIP>/v2/: dial tcp <SOMEIP>:443: connect: connection refused. Trying to figure out whether the registry addon and the --insecure-registry flag passed to minikube start are even related and if so, why the

Thanks  @astefanutti ! Got your comment from the other issue earlier :) Unfortunately, I've not been able to get that to work yet. Tried passing the flag to the minikube start command minikube start --driver=none --insecure-registry "10.0.0.0/24", but that does not enable the registry pods which cases the ./kamel install command to fail with error:
# ./kamel install
Error: cannot find automatically a registry where to push images

So, I executed minikube addons enable registry which started the registry and registry proxy pods, but resulted in the same error as before Unknown desc = Error response from daemon: Get https://<SOMEIP>/v2/: dial tcp <SOMEIP>:443: connect: connection refused. Trying to figure out whether the registry addon and the --insecure-registry flag passed to minikube start are even related and if so, why the

@amitsadaphule sorry I posted in the wrong issue 😄.
On Minikube, kamel install auto-configures the registry by looking up a Service annotated with "kubernetes.io/minikube-addons": "registry" in the kube-system namespace. This is what minikube addons enable registry is supposed to configure.
Let me know your findings.

@amitsadaphule sorry I posted in the wrong issue 😄.
On Minikube, kamel install auto-configures the registry by looking up a Service annotated with "kubernetes.io/minikube-addons": "registry" in the kube-system namespace. This is what minikube addons enable registry is supposed to configure.
Let me know your findings.

So, as per your comment, I checked the service configuration.
# kubectl describe svc registry -n kube-system
Name:              registry
Namespace:         kube-system
Labels:            addonmanager.kubernetes.io/mode=Reconcile
                   kubernetes.io/minikube-addons=registry
Annotations:       <none>
Selector:          actual-registry=true,kubernetes.io/minikube-addons=registry
Type:              ClusterIP
IP:                10.103.54.77
Port:              http  80/TCP
TargetPort:        5000/TCP
Endpoints:         172.17.0.5:5000
Port:              https  443/TCP
TargetPort:        443/TCP
Endpoints:         172.17.0.5:443
Session Affinity:  None
Events:            <none>

And I see the same IP in the failing pod's description
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  35s                default-scheduler  Successfully assigned default/sample-bb48bbd57-dn97b to x006vm57
  Normal   Pulling    22s (x2 over 34s)  kubelet, x006vm57  Pulling image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a"
  Warning  Failed     22s (x2 over 34s)  kubelet, x006vm57  Failed to pull image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a": rpc error: code = Unknown desc = Error response from daemon: Get https://10.103.54.77/v2/: dial tcp 10.103.54.77:443: connect: connection refused
  Warning  Failed     22s (x2 over 34s)  kubelet, x006vm57  Error: ErrImagePull
  Normal   BackOff    10s (x2 over 34s)  kubelet, x006vm57  Back-off pulling image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a"
  Warning  Failed     10s (x2 over 34s)  kubelet, x006vm57  Error: ImagePullBackOff

And as per https://github.com/apache/camel-k/blob/master/pkg/install/operator.go#L310, for minikube, the installation is already configured to use insecure registry (still, tried ./kamel install --insecure-registry=true). So, I'm not sure why the pull is tried on port 443 (https), instead of 5000 (http). I'll try and have a look at the ./kamel run command handling.

So, as per your comment, I checked the service configuration.
# kubectl describe svc registry -n kube-system
Name:              registry
Namespace:         kube-system
Labels:            addonmanager.kubernetes.io/mode=Reconcile
                   kubernetes.io/minikube-addons=registry
Annotations:       <none>
Selector:          actual-registry=true,kubernetes.io/minikube-addons=registry
Type:              ClusterIP
IP:                10.103.54.77
Port:              http  80/TCP
TargetPort:        5000/TCP
Endpoints:         172.17.0.5:5000
Port:              https  443/TCP
TargetPort:        443/TCP
Endpoints:         172.17.0.5:443
Session Affinity:  None
Events:            <none>

And I see the same IP in the failing pod's description
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  35s                default-scheduler  Successfully assigned default/sample-bb48bbd57-dn97b to x006vm57
  Normal   Pulling    22s (x2 over 34s)  kubelet, x006vm57  Pulling image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a"
  Warning  Failed     22s (x2 over 34s)  kubelet, x006vm57  Failed to pull image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a": rpc error: code = Unknown desc = Error response from daemon: Get https://10.103.54.77/v2/: dial tcp 10.103.54.77:443: connect: connection refused
  Warning  Failed     22s (x2 over 34s)  kubelet, x006vm57  Error: ErrImagePull
  Normal   BackOff    10s (x2 over 34s)  kubelet, x006vm57  Back-off pulling image "10.103.54.77/default/camel-k-kit-c07d5umf4tgvn7jat3d0@sha256:763e96a74417211f129c0b35560e458ac50d766993bc0f56707986a87e60ae4a"
  Warning  Failed     10s (x2 over 34s)  kubelet, x006vm57  Error: ImagePullBackOff

And as per https://github.com/apache/camel-k/blob/master/pkg/install/operator.go#L310, for minikube, the installation is already configured to use insecure registry (still, tried ./kamel install --insecure-registry=true). So, I'm not sure why the pull is tried on port 443 (https), instead of 5000 (http). I'll try and have a look at the ./kamel run command handling.

Right, it doesn't seem like a Camel K issue to me. It's the Kubelet that is not configured to pull from the insecure registry. I would dig into https://minikube.sigs.k8s.io/docs/handbook/registry/#enabling-insecure-registries. I think that minikube start --insecure-registry "10.0.0.0/24" must be done at creation time, that is the first time the cluster get started, otherwise the option may be ignored.

Right, it doesn't seem like a Camel K issue to me. It's the Kubelet that is not configured to pull from the insecure registry. I would dig into https://minikube.sigs.k8s.io/docs/handbook/registry/#enabling-insecure-registries. I think that minikube start --insecure-registry "10.0.0.0/24" must be done at creation time, that is the first time the cluster get started, otherwise the option may be ignored.

Right, tried stopping, deleting (+ rm -rf ~/.minikube ~/.kube) and re-creating with minikube start --insecure-registry "10.0.0.0/24", with no luck. Something very strange is going on there. Thanks for the pointer! I'll debug in that direction. :)

Right, tried stopping, deleting (+ rm -rf ~/.minikube ~/.kube) and re-creating with minikube start --insecure-registry "10.0.0.0/24", with no luck. Something very strange is going on there. Thanks for the pointer! I'll debug in that direction. :)

authors: amitsadaphule astefanutti tadayosi

repo: apache/camel-k


text:
Evaluate how we can fully support fa(s)t-jar execution

While working on #5488 I realized we have certain limitations/assumptions in the way we require to execute the jvm from the Camel application container Pod. It turns out that, due to the usage of Joor and its limitations (see [1]) we cannot make a reliable usage of the fast-jar (and eventually fat-jar if/when we move to managed Springboot).
I think the root cause is coming from the fact that we're loading the routes dynamically, ie, we create a generic project, and at runtime we inject the route into the Camel context and start it (please, @lburgazzoli correct me if this is wrong). This was a cornerstone of the reusability of an IntegrationKit which spared some time to build a new project. However, I wonder if this is a design we still want to maintain as it gives us certain limitations, and, remove the parity between a normal Camel (Quarkus) development and Camel K.
If we instead let the build to consider the route at runtime, we should be able to use the fa(s)t-jar and leverage the default Camel mechanism to load a route. Of course, the trade off is that we would be losing the possibility to reuse the same IntegrationKit for different Integrations as, each of them would be including the route into the build. We should understand if this design can still be compatible with incremental image [2] (I think it does, since the route would be contained in the built dependency which is going to be replaced in the new Kit created).
This is something to address in a major release, as it would break existing Integrations compatibility, but I think that it is a good opportunity to collect feedback to be ready when this is coming.
[1] https://github.com/jOOQ/jOOR/issues/69
[2] https://camel.apache.org/camel-k/next/architecture/incremental-image.html

The redesign of this part would probably gives us the possibility to move to a jre (and distroless) base image, reducing the CVE surface area and the size of each image (see also #3743)

This looks like an interesting move to me also. Currently when we update the kamelets we have issues with inconsistency between the kamelets' definitions and the dependencies already contained in the images (Explained in this forum's post).
Having all routes and dependencies inside the image would definitely avoid this issue.

source: gharchive/issue

authors: Exether squakez

license_type: permissive

license_source: github-api


text:
Ref #3023: Add native compilation with sources

Release Note
NONE

BTW, if you want to run the native test suite as well, you need to call the native workflow directly on the branch as we have moved them into nightly releases (they used to eat up a lot of memory).

As I'm working on some ideas around Camel K 2.0 (gitops, being able to build any Camel application, ...), let me share with you something I've been thinking lately. I may probably create an issue with some visual support, but hopefully can help you in the work you're doing.
I think that instead of passing the whole content of a source along the different CRs, we should have the concept of a "generated Maven project" (it may even come from camel export - Camel JBang instead of our own logic). This is a standard Maven project that could be even stored in a Git repository. The project should be generated by the Operator when an Integration is submitted (here we can think to provide the Source or the Git repo URL). In the first case a project generation is triggered (ie, via Camel JBang)  and we should store temporary the result in a workspace directory. The project generation may be controlled via a new Custom Resource and a reconciliation loop.
Once the Project is ready, the Build can kick off. The Build has to be fed with the workspace directory and the rest should be proceeding more or less the same way it is now (in order to be able to reuse the incremental image kit logic).

Details of the proposal defined in the previous comment exposed in #4024

Your idea is great however it is scoped to Camel K 2.0 while I would expect a solution for Camel K 1.17, don't you believe that it could be an acceptable approach for 1.17?

Your idea is great however it is scoped to Camel K 2.0 while I would expect a solution for Camel K 1.17, don't you believe that it could be an acceptable approach for 1.17?

I guess you mean 1.12.0 (1.17 is the runtime). It could work, but mind that we could apply an heavy refactoring when moving to 2.0.

@squakez your remarks have been addressed.
What remains:

The test TestOLMAutomaticUpgrade fails and it is not clear to me why. I see this test fails in another build so I guess it is not related to these changes.
There are some tests failing due to what you fixed in this PR https://github.com/apache/camel-k/pull/4029
Some tests that I have added for native mode due to a lack of memory, maybe I should only keep the less greedy, WDYT?

Cool, I still need to have a deeper look, but in the while, about the native test I suggest you move them into a separate workflow (similar of what we used to have before) so that they won't timeout because the rest of the common already takes almost 3 hours and I bet, native only now may take a few more hours.

Infortunatelly the native E2E test cannot pass on the GitHub CI because it requires more than 6 Go of RAM, so I need to remove it.

Infortunatelly the native E2E test cannot pass on the GitHub CI because it requires more than 6 Go of RAM, so I need to remove it.

Have you rebased it? it seems there was some failure I've fixed in #4022 - we need to find a way to run the native check smoothly anyhow, maybe we can run it as an additional nightly task right after the release task (to avoid resource consumption conflict).

Have you rebased it? it seems there was some failure I've fixed in #4022

Yes I rebased it already

I added some unit tests

FYI, the build is not failing because of these changes since the same errors occur on a different PR

Depends on https://github.com/container-tools/kind-action/pull/10

Depends on container-tools/kind-action#10

Great finding. If we manage to run with more resources we may have a more complete test for native!

Depends on https://github.com/container-tools/kind-action/pull/12 (memory allocated to Colima by default is too low)

knative check failure because of #4044 - if the rest of checks pass we can merge :crossed_fingers:

Sounds good to be reviewed now, the build native / install-native only failed during the cleanup phase, the tests pass

Good for me. As it's all green let's merge this :) - we will understand if moving the native workflow to a daily basis if we see it start becoming too much resource consuming.

Excellent work. Great feature to promote for 1.12.0 release!

source: gharchive/pull-request

authors: essobedo squakez


text:
fix(knative): Integration in error state when knative SinkBinding mode=inclusion (1.10.x branch)

https://github.com/apache/camel-k/issues/4119
This is the backport of https://github.com/apache/camel-k/pull/4120 to 1.10.x branch
Release Note
knative trait sets `bindings.knative.dev/include=true` label to the namespace when there is a SinkBinding.

I think we should backport to release 1.12 as well.


text:
Upgrade Camel K CRDs to 2.0.1

Use Kamelet v1 instead of v1alpha1
Keeping KameletBinding and not migrating to Pipes as it is used only in tests and not yet supported in a released version Camel Jbang
part of #1562

current failure:
https://github.com/apupier/camel-kamelets/actions/runs/6082723370/job/16501217219?pr=5#step:7:171
Error:  [ERROR] Unknown catalog 'citrusframework/yaks'

All seems good. @christophd do you mind have a look too?

(reminder that I'm not a committer and cannot merge the Pull Request to be sure that nobody i awaiting for me to merge it)

authors: apupier oscerd

repo: apache/camel-kamelets


text:
Adding additional logging to scope creation and closing

the problem we have is that one of the spans in one of the tests (most probably MulticastRouteTest) is not being closed and the span is left in the test thread. Due to this other tests are failing.
This PR removes the workaround that conditionally closes scopes. With these changes we're always closing scopes even multiple times.
related to pr gh-10539
closes https://issues.apache.org/jira/browse/CAMEL-19569

I think that should fix things cc @davsclaus @oscerd @ppalaga

Thanks @marcingrzejszczak do you know if we need to backport this to 3.x LTS branches?

I'll check it out tomorrow

Do we observe any issues with the builds for other branches? Which branches are the LTS ones? 3.21.x, 3.20.x, 3.18.x, 3.14.x ?

I dont think we have seen this, but some of these branches may had a JDK11 compile problem that we didnt got attention (we are busy with v4)
The latest JDK17 on 3.x seems not to have micrometer/observer any problems
https://ci-builds.apache.org/job/Camel/job/Camel JDK17/job/camel-3.x/lastCompletedBuild/testReport/

So maybe we shouldn't touch that code unless we see that there are issues? WDYT?

Yes we assume 3.x is all good for now, thanks.

authors: davsclaus marcingrzejszczak

repo: apache/camel


text:
Use secure repository URL

maven.restlet.org : Valid TLS certificate only for maven.restlet.com
springsource.com : Repository unnecessary
apache snapshots: Use TLS.

Merged on master. Thanks.

authors: oflebbe oscerd


text:
(chores) camel 4: adjust the contribution template to help users identify the correct branch

Description

Target

[x] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[x] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[x] I checked that each commit in the pull request has a meaningful subject line and body.

[x] I formatted the code using mvn -Pformat,fastinstall install && mvn -Psourcecheck

I adjusted the template to take into consideration Camel 3 and Camel 4.
@oscerd / @davsclaus should we keep this templated enabled by default during Camel 4 development? Any thoughts?

Sounds good to me. We should harmonize the template even in the subprojects though. Not only for Camel 3/Camel 4, but in general

Sounds good to me. We should harmonize the template even in the subprojects though. Not only for Camel 3/Camel 4, but in general

Yeah. I've been thinking about cleaning up our contribution guides. Having a common template would make things easier too.

authors: orpiske oscerd


text:
LDAP users with similar permissions do not see each other's networks

ISSUE TYPE

Bug Report
Improvement Request

COMPONENT NAME

LDAP, Network, UI

CLOUDSTACK VERSION

4.12

CONFIGURATION

Advanced networking with network service offering

OS / ENVIRONMENT

CentOS 7
SUMMARY

In one domain (eg. ROOT):
Admin create network offering
LDAP root admin user create network with network offering
Another LDAP root admin user not see this network

STEPS TO REPRODUCE

Create two LDAP users with root admin permissions and create networks.

EXPECTED RESULTS

All users in one domain with root admin privileges have the same capabilities (in this case, they can create a VM with a network created by another user).

ACTUAL RESULTS

LDAP user with root admin privileges can not see the networks created by the standard admin user (on the same domain). If such a user (ldap) with root admin privileges creates a new network, it is not visible to other users in UI
I consider this to be an error which makes work with users with root admin privileges very difficult

Heard a similar thing from another user.
"LDAP-authenticated" ADMIN vs. "local-authenticated" ADMIN - can't see each other's networks.

Are these the same root admin account or two accounts which both have root admin privileges?

Two accounts with root admin privileges:
ppisz | Root Admin | Admin | ROOT | enabled
tome | Root Admin | Admin | ROOT | enabled

Is the other network visible through the API (when you use listall=true) ?

LDAP root admin sees all networks through the API (not in UI).
Real admin see all networks in UI.

Can you test Primate @PPisz we're targeting GA/1.0 now

ping @PPisz cc @Spaceman1984 @shwstppr @Pearl1594

cc @svenvogel @utchoang can you test in the new UI?

@PPisz I reviewed the ticket again, per your comment there are two accounts:
Two accounts with root admin privileges:

ppisz | Root Admin | Admin | ROOT | enabled
tome | Root Admin | Admin | ROOT | enabled

Since resources are owned by account, they are treated different entities/owners even if they may have the same user (physical person) who has LDAP access to both accounts. If my understanding is correct, this is by design and not a CloudStack bug.

@PPisz pl check and close the ticket, or help explain for further investigation. Thanks.

@rhtyd

I checked it in 4.15 on Primate, no change.
I understand that it was designed this way, I am closing the ticket.

Thanks @PPisz I need one case to be checked which on behaviour when there are multiple root admins. I'm temporarily opening the ticket. Will close of it turns out to be a non issue.

Thanks @PPisz I need one case to be checked which on behaviour when there are multiple root admins. I'm temporarily opening the ticket. Will close of it turns out to be a non issue.

@rhtyd are you testing the case or should I go ahead?

@Spaceman1984 pl test by creating two root admin accounts and compare the UI vs legacy UI.

I tested with multiple root admin accounts, not an issue in 4.14 or 4.15.
I didn't test 4.12. and I didn't specifically test with an LDAP admin user.

Thanks Darrin, closing on your remark

authors: PPisz PaulAngus Spaceman1984 andrijapanicsb rhtyd

repo: apache/cloudstack


text:
Host HA not working properly

ISSUE TYPE

Bug Report

COMPONENT NAME

NFS Primary Storage

CLOUDSTACK VERSION

4.18.1.0

CONFIGURATION

advanced networking
primary storage on NFSv3
host ha enabled on the cluster with a specific host dedicated to HA
OS / ENVIRONMENT

management server with OS centOS7
hosts with OS Ubuntu 22.04
SUMMARY

If I shutdown a host, it keeps a lock on NFS mount that prevent all VMs that were running on it to automatically restart on the dedicated HA host.
Also the lock prevents to start these VMs until the host is online again and able to release the lock.
STEPS TO REPRODUCE

In a cluster with primary storage NFSv3, shutdown a host with VMs running on it

EXPECTED RESULTS

The lock is released as soon as the host is down, or after a short delay.

ACTUAL RESULTS

The lock is not released until the host is back online

@cdfgallo this sounds like an issue with nfs where locks are kept until a proper umount has been done. I would expect this to happen if a host gracefully shuts down. if a host crashes it would not happen, at least not in older nfs versions afairc.
we might have to add a shutdown script to take care of that, but that will only help on gracefull shutdowns.

@DaanHoogland this issue happens when a host is not gracefully shutdown (lost power) or it lose network connections.
I haven't tried to shutdown gracefully the host as I would put it into maintenance mode before doing so.

@DaanHoogland this issue happens when a host is not gracefully shutdown (lost power) or it lose network connections. I haven't tried to shutdown gracefully the host as I would put it into maintenance mode before doing so.

I don't think that test would make a lot of sense in real life. Can you test this setup with NFSv4

So it is an expected behaviour that a host being down keeps the lock on VMs file on NFSv3? In this case we need for sure to try NFSv4

this is a downside of NFSv3, yes.

On NFS4 I have no issues. I'm closing this issue. Thank you @DaanHoogland !

authors: DaanHoogland cdfgallo


text:
CLOUDSTACK-9057 remove old system vm upgrade code

the upgrade step to 4.5 system templates is removed for 4.6 in this. validation would be to install any 4.4.2 or lower version and upgrade to 4.6. It would only require the templates for 4.6 and not the ones for 4.5. as it would before this patch. only unittests performed hence for all practical purposes untested.

LGTM
that is what we did for previous versions

Since this code is only needed if you upgrade to 4.5 not when you hit this code if you upgrade from say 4.4 and jump forward to 4.6. This code is still needed in the 4.5 branch but not here.
We should run an upgrade test to verify.

I will test the upgrade, @DaanHoogland and LGTM afterwards.
Cheers,
Wilder

@remibergsma @wilderrodrigues @karuturi is anything to be done with this?

@DaanHoogland Yes, please make this PR towards 4.6 please.

#1072 contains this code to be merged on 4.6 (and rebased on post-release commit)

authors: DaanHoogland remibergsma ustcweizhou wilderrodrigues


text:
Restart agent when host comes out of maintenance

Description
This PR...
Fixes #9295
New storage pools are not added to a host which is in maintenance. This change will restart the agent when host is taken out of maintenance mode. StoragePoolMonitor.processConnect() will then get called which will add/mount the new storage pool to the host.
One more related issue was that storage pool was not getting unmounted from a host in maintenance mode. Even when the host is taken out of maintenance mode, it will still have the pool mounted. Only reboot will unmount the pool.
So, as fix have added DeleteStoragePoolCommand to be able to run in maintenance mode similar to ModifyStoragePoolCommand.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)
[ ] build/CI
[ ] test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

How did you try to break this feature and the system with this change?

@blueoraguntan package

@blueorangutan package

@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10111

@blueorangutan test

@abh1sar a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

@blueorangutan package

@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10124

[SF] Trillian test result (tid-10612)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 42162 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9301-t10612-kvm-centos7.zip
Smoke tests completed. 107 look OK, 3 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

test_08_migrate_vm
Error
45.85
test_vm_life_cycle.py

test_01_cancel_host_maintenace_with_no_migration_jobs
Error
114.46
test_host_maintenance.py

test_disable_oobm_ha_state_ineligible
Error
1513.05
test_hostha_kvm.py

test_hostha_enable_ha_when_host_in_maintenance
Failure
310.26
test_hostha_kvm.py

@blueorangutan test

@abh1sar a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[SF] Trillian test result (tid-10626)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 41860 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9301-t10626-kvm-centos7.zip
Smoke tests completed. 107 look OK, 3 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

test_08_migrate_vm
Error
45.92
test_vm_life_cycle.py

test_01_vpc_site2site_vpn
Failure
279.86
test_vpc_vpn.py

test_hostha_enable_ha_when_host_disabled
Error
3.68
test_hostha_kvm.py

test_hostha_enable_ha_when_host_in_maintenance
Error
302.87
test_hostha_kvm.py

test_hostha_kvm_host_recovering
Error
7.13
test_hostha_kvm.py

@blueorangutan test kkepEnv

@blueorangutan test keepEnv

@abh1sar a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Working on resolving smoke test failures

codewise lgtm
@abh1sar
what about other resource states, like ErrorInMaintenance or ErrorInPrepareForMaintenance, PrepareForMaintenance ?

[SF] Trillian test result (tid-10648)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 45084 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9301-t10648-kvm-centos7.zip
Smoke tests completed. 109 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

test_hostha_enable_ha_when_host_disabled
Error
4.74
test_hostha_kvm.py

test_hostha_enable_ha_when_host_in_maintenance
Error
302.76
test_hostha_kvm.py

The approach of ssh-ing into the in-maintenance-host to restart the agent even if the agent was already connected is not right, as it breaks the change done in https://github.com/apache/cloudstack/pull/3239
I think better solution would be to allow createStoragePoolCommand to run on the host in maintenance mode (like ModifyStoragePoolCommand)
@sureshanaparti @kiranchavala

The approach of ssh-ing into the in-maintenance-host to restart the agent even if the agent was already connected is not right, as it breaks the change done in #3239
I think better solution would be to allow createStoragePoolCommand to run on the host in maintenance mode (like ModifyStoragePoolCommand)
@sureshanaparti @kiranchavala

Yes @abh1sar, If the agent is already connected, better check & update the storage pools with agent command.

@blueorangutan package

@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

codewise lgtm
@abh1sar what about other resource states, like ErrorInMaintenance or ErrorInPrepareForMaintenance, PrepareForMaintenance ?

Have changed the approach, so this code is now obsolete. Please check.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10184

@blueorangutan test

@abh1sar a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[SF] Trillian test result (tid-10670)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 39649 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9301-t10670-kvm-centos7.zip
Smoke tests completed. 109 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

test_hostha_kvm_host_fencing
Error
106.67
test_hostha_kvm.py

authors: abh1sar blueorangutan sureshanaparti weizhouapache


text:
Remove redundant (null) initializations

Change

removes redundant (null) initializations
removes redundant int initializations
removes redundant close() methods from try-with-resources handled code blocks
clears some unused imports

FYI: @garydgregory @kinow

Codecov Report

Merging #394 (4d72666) into master (f884b86) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #394      +/-   ##
============================================
- Coverage     80.45%   80.44%   -0.01%
  Complexity     6723     6723
============================================
  Files           343      343
  Lines         25310    25291      -19
  Branches       4107     4107
============================================
- Hits          20363    20346      -17
+ Misses         3366     3364       -2
  Partials       1581     1581

Impacted Files
Coverage Δ

.../compress/archivers/arj/ArjArchiveInputStream.java
73.05% <ø> (-0.17%)
:arrow_down:

.../commons/compress/archivers/examples/Expander.java
86.66% <ø> (-0.13%)
:arrow_down:

...compress/archivers/tar/TarArchiveOutputStream.java
88.61% <ø> (ø)

...ommons/compress/archivers/zip/ZipArchiveEntry.java
82.29% <ø> (-0.05%)
:arrow_down:

...compress/archivers/zip/ZipArchiveOutputStream.java
74.19% <ø> (-0.05%)
:arrow_down:

...ss/compressors/gzip/GzipCompressorInputStream.java
68.57% <ø> (-0.30%)
:arrow_down:

...compressors/lz4/BlockLZ4CompressorInputStream.java
74.13% <ø> (-0.44%)
:arrow_down:

...mpressors/snappy/SnappyCompressorOutputStream.java
85.05% <ø> (-0.17%)
:arrow_down:

...ns/compress/harmony/pack200/MetadataBandGroup.java
70.64% <ø> (-0.14%)
:arrow_down:

...mons/compress/harmony/pack200/PopulationCodec.java
81.15% <ø> (+1.15%)
:arrow_up:

... and 9 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: codecov-commenter mawiesne

repo: apache/commons-compress


text:
LANG-1733: Add null handling features working with Java 8 specs

JIRA Ticket: LANG-1733
Suggestion: Introduce null handling features working with with the java.util.function package, or more generally, with Java 8 lambdas.

It simplifies null handling by eliminating unnecessary steps such as using specific types or if/else statements.
It reduces the overhead associated with managing objects like the Optional type.
It decreases the complexity involved in other null handling methods.

@garydgregory Have to admit, that even I don't understand, what you are suggesting?

Codecov Report
Attention: Patch coverage is 80.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 92.51%. Comparing base (f962e7b) to head (547eded).
Report is 145 commits behind head on master.

Files
Patch %
Lines

...che/commons/lang3/function/NullSafeOperations.java
80.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1215      +/-   ##
============================================
+ Coverage     92.07%   92.51%   +0.43%
- Complexity     7587     7746     +159
============================================
  Files           200      201       +1
  Lines         15844    15892      +48
  Branches       2890     2819      -71
============================================
+ Hits          14589    14702     +113
+ Misses          682      654      -28
+ Partials        573      536      -37

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Our Suppliers class implements a null-safe get method. If you want to do a null-safe version of accept for Consumers, then that new method should go in our Consumers class, not a new class.

Thanks for your feedback.
I moved null handling features to Consumers and Functions class in the function package.

Thank you for your feedback.
I applied most of feedbacks. but the name suggestion is not good for me.
I think your suggestion is short and easy but the existing name describes the functionality of the method more accurately.

Well, you can change the names now, and save me the work, or I'll change them after I review the PR and it is merged...

@garydgregory
Initially, I added apis that only work when the object is null. In this case, there were many useful call sites in this project. (e.g. ArrayFill.fill()) After applying https://github.com/apache/commons-lang/pull/1215#discussion_r1611600920, these apis accepted null as valid input and lost null-safe functionality.
This is not my intent. If you want to apply a functional interface regardless of whether the object is null or not, making other methods is better than fixing existing methods.
What do you think about my opinion?

@imbf
The latest changes break the build.
Run 'mvn' by itself to run all build checks before you push.

authors: codecov-commenter garydgregory imbf jochenw

repo: apache/commons-lang

license_source: bigquery


text:
Partially revert LANG-1172.

The changes for LANG-1172 changed the allowed input and expectations of LocaleUtils.toLocale to now also support strings which include '-'.  This change reverts that behavior, but leaves support for it through a protected method.

@seadbrane
Why?
CC: @c-w

https://github.com/apache/commons-lang/pull/766#issuecomment-1912667376

Any update?  Also, I did not expect this to be the final revision - as I wasn't sure the preferred method signature for supporting strings with '-', which is why I left this as a protected method now.
Options:

Make the toLocale(String, boolean) method public
Expose a new method such as toLocaleLenient(String)

I can understand the reluctance to rolling this back, as I am sure there are now folks relying on the new behavior.
Although in addition to breaking the previous contract, the current behavior muddies the waters on the differences between locale and language tags, and I am concerned that more folks will now think of them and try to treat them as equivalent - which is not the case conceptually or from a string representation perspective.

@seadbrane
If you want this issue to get more visibility, you should consider posting to the developer's mailing list https://commons.apache.org/mail-lists.html

Hi @garydgregory
I see you posted something on the email list already - thank you.   I was not subscribed to the list at the time and looks like no responses- mind pinging the thread, or is preferred to start a new one?
Related:  The javadoc for this method the following up through 3.12.0.
"This method validates the input strictly. The language code must be lowercase. The country code must be uppercase. The separator must be an underscore. The length must be correct. "

authors: garydgregory seadbrane


text:
77984 upgrade mrargs record4

Upgrade #mrargs{} record in two steps.
First release would have following

fabric Compatibility clause for the record upgrade
mrview Merge remote-tracking branch 'cloudant/COUCHDB-3150-add-new-function-to-get-view-index-pid'

Second release would have

fabric  	Revert "Revert "Merge remote-tracking branch 'banjiewen/stale-stable-..
mrview Merge remote-tracking branch 'banjiewen/stale-stable-update'

nicely done. +1

Yes, but make this two PRs so that you can merge them intelligently. Took me a few minutes to realize that your PR description is saying this goes into two different releases. People are going to want to have two different commits on master to select between if they're doing similar rolling upgrades. Having those two commits on one side of a merge branch seems unwise.

fair point.

On 14 Nov 2016, at 23:47, Paul J. Davis notifications@github.com wrote:
Yes, but make this two PRs so that you can merge them intelligently. Took me a few minutes to realize that your PR description is saying this goes into two different releases. People are going to want to have two different commits on master to select between if they're doing similar rolling upgrades. Having those two commits on one side of a merge branch seems unwise.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

This is the first phase PR https://github.com/apache/couchdb-fabric/pull/77

Second phase PR https://github.com/apache/couchdb-fabric/pull/78

Closing it in favor of already merged:

https://github.com/apache/couchdb-fabric/issues/78
https://github.com/apache/couchdb-fabric/issues/77
https://github.com/apache/couchdb-fabric/pull/80

authors: davisp iilyak rnewson

repo: apache/couchdb-fabric