From commits-return-87553-archive-asf-public=cust-asf.ponee.io@camel.apache.org  Tue Feb 11 15:48:52 2020
Return-Path: <commits-return-87553-archive-asf-public=cust-asf.ponee.io@camel.apache.org>
X-Original-To: archive-asf-public@cust-asf.ponee.io
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [207.244.88.153])
	by mx-eu-01.ponee.io (Postfix) with SMTP id 64A7818063F
	for <archive-asf-public@cust-asf.ponee.io>; Tue, 11 Feb 2020 16:48:52 +0100 (CET)
Received: (qmail 12205 invoked by uid 500); 11 Feb 2020 15:48:51 -0000
Mailing-List: contact commits-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@camel.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@camel.apache.org>
List-Post: <mailto:commits@camel.apache.org>
List-Id: <commits.camel.apache.org>
Reply-To: dev@camel.apache.org
Delivered-To: mailing list commits@camel.apache.org
Received: (qmail 12196 invoked by uid 99); 11 Feb 2020 15:48:51 -0000
Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Feb 2020 15:48:51 +0000
From: GitBox <git@apache.org>
To: commits@camel.apache.org
Subject: [GitHub] [camel-k] nicolaferraro commented on issue #1206: Knative services
 are slow to become ready
Message-ID: <158143613166.25597.11311883945134966473.gitbox@gitbox.apache.org>
References: <infra.1206.MDU6SXNzdWU1NTAyOTg1NDA=.gitbox@gitbox.apache.org>
In-Reply-To: <infra.1206.MDU6SXNzdWU1NTAyOTg1NDA=.gitbox@gitbox.apache.org>
Date: Tue, 11 Feb 2020 15:48:51 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

nicolaferraro commented on issue #1206: Knative services are slow to become ready
URL: https://github.com/apache/camel-k/issues/1206#issuecomment-584701736
 
 
   I think I've isolated the issue.
   
   This kservice is fast to start:
   
   ```
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     labels:
       camel.apache.org/generation: "1"
       camel.apache.org/integration: fast-printer
     name: fast-printer
     namespace: default
   spec:
     template:
       metadata:
         labels:
           camel.apache.org/generation: "1"
           camel.apache.org/integration: fast-printer
       spec:
         containerConcurrency: 0
         containers:
         - args:
           - org.apache.camel.k.main.Application
           command:
           - java
           image: camelk/camel-k-kit-bp1c6ngo4v80887bt9h0:9311
           name: integration
           readinessProbe:
             successThreshold: 1
             tcpSocket:
               port: 0
           workingDir: /deployments
         timeoutSeconds: 300
     traffic:
     - latestRevision: true
       percent: 100
   ```
   
   This one is slow:
   ```
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     labels:
       camel.apache.org/generation: "1"
       camel.apache.org/integration: fast-printer
     name: fast-printer
     namespace: default
   spec:
     template:
       metadata:
         labels:
           camel.apache.org/generation: "1"
           camel.apache.org/integration: fast-printer
       spec:
         containerConcurrency: 0
         containers:
         - args:
           - org.apache.camel.k.main.Application
           command:
           - java
           image: 10.107.75.139/default/camel-k-kit-bp1c6ngo4v80887bt9h0:9311
           name: integration
           readinessProbe:
             successThreshold: 1
             tcpSocket:
               port: 0
           workingDir: /deployments
         timeoutSeconds: 300
     traffic:
     - latestRevision: true
       percent: 100
   
   ```
   
   The only difference is that (the fast) one uses an image from `docker.io`, while the other uses the Minikube internal registry `10.107.75.139`.
   The serving controller tries to do something with that registry before starting the ksvc and remains stale.
   
   My best guess is that the serving controller tries to contact it on https port `443`, but the service never replies on that port (in fact `curl` reaches a timeout) and the controller remains waiting forever.
   
   Does this sound familiar to you @markusthoemmes ?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services