On Thu, Feb 18, 2016 at 5:14 PM, Candide Kemmler <[email protected]> wrote:
> I did it all from scratch again (delete/re-created the project). > > oc get event: > > https://gist.github.com/ckemmler/a4bda6af62dc3b6daa01 > > logs for intrinsic-pfs deployment are empty ("An error occured loading the > log") > > Happy to take this to another channel (irc?) > > Thank *you* for helping me with this! > > > A quick IRC session could be easier... I'm `danmace` in #openshift-dev on Freenode. > On 18 Feb 2016, at 23:01, Dan Mace <[email protected]> wrote: > > > > On Thu, Feb 18, 2016 at 4:46 PM, Candide Kemmler <[email protected]> > wrote: > >> Also, here is the template I'm using to try to create the app, if it >> helps: >> >> https://gist.github.com/ckemmler/72738543f9aec97a3bca >> >> Just retried to create the app, here's the output of 'oc get pod -o yaml' >> >> https://gist.github.com/ckemmler/6de93bc17b9ed8208d4f >> > > > Looks like the pods associated with your new replicationController (aka > deployment) are stuck "Pending" and don't have any status indicating > they've been scheduled on a node. During the time of the hung deployment > process, do you see any logs from the master related to the scheduling of > 'intrinsic-pds-1-', or any events? Try: > > `oc get event` > > From what I have seen so far, the problem could be that the deployer > process scaled up the RC to 1, but the pod for the RC never becomes ready, > possibly because of a scheduling issue. Events and logs will hopefully tell > us more. > > Thanks for your patience diagnosing this. > >> On 18 Feb 2016, at 22:36, Dan Mace <[email protected]> wrote: >> >> >> >> On Thu, Feb 18, 2016 at 4:32 PM, Candide Kemmler <[email protected] >> > wrote: >> >>> Clayton, I don't know that's what I get from running "oc get dc >>> intrinsic-pds": >>> >>> [admin@paas pds]$ oc get dc/intrinsic-pds -o yaml >>> Error from server: deploymentConfig "\u200bi\u200bntrinsic-pds" not found >>> [admin@paas pds]$ oc get dc/intrinsic-pds >>> Error from server: deploymentConfig "\u200bi\u200bntrinsic-pds" not found >>> >>> Anyway getting all deploymentconfigs works: >>> >> >> Okay, so next I'm curious to know if the pods or containers for the >> newly deployed RC are failing to be created or are stuck in a crash-loop. >> While the deployment is waiting, can you take a look at the >> replicationControllers: >> >> `oc get rc -o yaml` >> >> And also the pods: >> >> `oc get pod -o yaml` >> >> >> >> >> >>> apiVersion: v1 >>> items: >>> - apiVersion: v1 >>> kind: DeploymentConfig >>> metadata: >>> creationTimestamp: 2016-02-18T20:33:44Z >>> labels: >>> template: couchdb-persistent-template >>> name: couchdb >>> namespace: intrinsic-dev >>> resourceVersion: "26314" >>> selfLink: /oapi/v1/namespaces/intrinsic-dev/deploymentconfigs/couchdb >>> uid: e79d7892-d67e-11e5-9c86-fa163e3b8107 >>> spec: >>> replicas: 1 >>> selector: >>> name: couchdb >>> strategy: >>> resources: {} >>> type: Recreate >>> template: >>> metadata: >>> creationTimestamp: null >>> labels: >>> name: couchdb >>> spec: >>> containers: >>> - image: >>> docker.io/intrinsic/couchdb@sha256:71fce8ab4ea3c148624e8d85a7cf3b49610b3d20cccfcc15a10572bdf1cca28c >>> imagePullPolicy: IfNotPresent >>> name: couchdb >>> ports: >>> - containerPort: 5984 >>> protocol: TCP >>> resources: {} >>> securityContext: >>> capabilities: {} >>> privileged: false >>> terminationMessagePath: /dev/termination-log >>> volumeMounts: >>> - mountPath: /usr/local/var/lib/couchdb >>> name: couch-data >>> dnsPolicy: ClusterFirst >>> restartPolicy: Always >>> securityContext: {} >>> terminationGracePeriodSeconds: 30 >>> volumes: >>> - name: couch-data >>> persistentVolumeClaim: >>> claimName: couchdb >>> triggers: >>> - imageChangeParams: >>> automatic: true >>> containerNames: >>> - couchdb >>> from: >>> kind: ImageStreamTag >>> name: couchdb:latest >>> namespace: openshift >>> lastTriggeredImage: >>> docker.io/intrinsic/couchdb@sha256:71fce8ab4ea3c148624e8d85a7cf3b49610b3d20cccfcc15a10572bdf1cca28c >>> type: ImageChange >>> - type: ConfigChange >>> status: >>> details: >>> causes: >>> - type: ConfigChange >>> latestVersion: 1 >>> - apiVersion: v1 >>> kind: DeploymentConfig >>> metadata: >>> creationTimestamp: 2016-02-18T21:19:05Z >>> labels: >>> app: intrinsic-pds >>> name: intrinsic-pds >>> namespace: intrinsic-dev >>> resourceVersion: "26863" >>> selfLink: >>> /oapi/v1/namespaces/intrinsic-dev/deploymentconfigs/intrinsic-pds >>> uid: 3d99e06b-d685-11e5-9c86-fa163e3b8107 >>> spec: >>> replicas: 1 >>> selector: >>> deploymentconfig: intrinsic-pds >>> strategy: >>> resources: {} >>> rollingParams: >>> intervalSeconds: 1 >>> maxSurge: 25% >>> maxUnavailable: 25% >>> timeoutSeconds: 600 >>> updatePeriodSeconds: 1 >>> type: Rolling >>> template: >>> metadata: >>> creationTimestamp: null >>> labels: >>> app: intrinsic-pds >>> deploymentconfig: intrinsic-pds >>> spec: >>> containers: >>> - env: >>> - name: jdbc_url >>> value: >>> jdbc:mysql://mysql:3306/intrinsic?useUnicode=true&connectionCollation=utf8mb4_unicode_ci&characterSetResults=utf8&characterEncoding=utf8&autoReconnect=true >>> - name: jdbc_username >>> value: *** >>> - name: jdbc_password >>> value: *** >>> - name: development_mode >>> value: "false" >>> - name: dns_suffix >>> value: apps.intrinsic.world >>> - name: couchdb_host >>> value: couchdb >>> image: >>> 172.30.122.240:5000/intrinsic-dev/intrinsic-pds@sha256:0d26174694f39e4b2d6996c7ec03fcbd17af981de62393c0462743e9a0f0dac6 >>> imagePullPolicy: Always >>> name: intrinsic-pds >>> ports: >>> - containerPort: 8080 >>> protocol: TCP >>> - containerPort: 8443 >>> protocol: TCP >>> - containerPort: 8778 >>> protocol: TCP >>> resources: {} >>> terminationMessagePath: /dev/termination-log >>> dnsPolicy: ClusterFirst >>> restartPolicy: Always >>> securityContext: {} >>> terminationGracePeriodSeconds: 30 >>> triggers: >>> - imageChangeParams: >>> automatic: true >>> containerNames: >>> - intrinsic-pds >>> from: >>> kind: ImageStreamTag >>> name: intrinsic-pds:latest >>> lastTriggeredImage: >>> 172.30.122.240:5000/intrinsic-dev/intrinsic-pds@sha256:0d26174694f39e4b2d6996c7ec03fcbd17af981de62393c0462743e9a0f0dac6 >>> type: ImageChange >>> - type: ConfigChange >>> status: >>> details: >>> causes: >>> - imageTrigger: >>> from: >>> kind: DockerImage >>> name: 172.30.122.240:5000/intrinsic-dev/intrinsic-pds:latest >>> type: ImageChange >>> latestVersion: 1 >>> - apiVersion: v1 >>> kind: DeploymentConfig >>> metadata: >>> creationTimestamp: 2016-02-18T20:26:58Z >>> labels: >>> template: mysql-persistent-template >>> name: mysql >>> namespace: intrinsic-dev >>> resourceVersion: "26218" >>> selfLink: /oapi/v1/namespaces/intrinsic-dev/deploymentconfigs/mysql >>> uid: f58518e0-d67d-11e5-9c86-fa163e3b8107 >>> spec: >>> replicas: 1 >>> selector: >>> name: mysql >>> strategy: >>> resources: {} >>> type: Recreate >>> template: >>> metadata: >>> creationTimestamp: null >>> labels: >>> name: mysql >>> spec: >>> containers: >>> - env: >>> - name: MYSQL_USER >>> value: *** >>> - name: MYSQL_PASSWORD >>> value: *** >>> - name: MYSQL_DATABASE >>> value: *** >>> image: >>> docker.io/centos/mysql-56-centos7@sha256:5a1d4c653e953c75a2834444cfecb1016ae57023b52ea12ad35ec0d1f861adb1 >>> imagePullPolicy: IfNotPresent >>> name: mysql >>> ports: >>> - containerPort: 3306 >>> protocol: TCP >>> resources: {} >>> securityContext: >>> capabilities: {} >>> privileged: false >>> terminationMessagePath: /dev/termination-log >>> volumeMounts: >>> - mountPath: /var/lib/mysql/data >>> name: mysql-data >>> dnsPolicy: ClusterFirst >>> restartPolicy: Always >>> securityContext: {} >>> terminationGracePeriodSeconds: 30 >>> volumes: >>> - name: mysql-data >>> persistentVolumeClaim: >>> claimName: mysql >>> triggers: >>> - imageChangeParams: >>> automatic: true >>> containerNames: >>> - mysql >>> from: >>> kind: ImageStreamTag >>> name: mysql:latest >>> namespace: openshift >>> lastTriggeredImage: >>> docker.io/centos/mysql-56-centos7@sha256:5a1d4c653e953c75a2834444cfecb1016ae57023b52ea12ad35ec0d1f861adb1 >>> type: ImageChange >>> - type: ConfigChange >>> status: >>> details: >>> causes: >>> - type: ConfigChange >>> latestVersion: 1 >>> kind: List >>> metadata: {} >>> >>> > On 18 Feb 2016, at 22:28, Clayton Coleman <[email protected]> wrote: >>> > >>> > What is "i\u200b"? Is that a unicode character? >>> > >>> > On Thu, Feb 18, 2016 at 4:23 PM, Candide Kemmler >>> > <[email protected]> wrote: >>> >> No there is no readiness proble in place. >>> >> >>> >> Really strange: here's what `oc get dc intrinsic-pds -o yaml` tells >>> me: >>> >> >>> >> Error from server: deploymentConfig "i\u200bntrinsic-pds" not found >>> >> >>> >> ??? >>> >> >>> >> On 18 Feb 2016, at 22:10, Dan Mace <[email protected]> wrote: >>> >> >>> >> On Thu, Feb 18, 2016 at 4:03 PM, Candide Kemmler < >>> [email protected]> >>> >> wrote: >>> >>> >>> >>> I have successfully created templates for all 5 microservices in our >>> >>> application but now, at the "deployment" phase, the pod will remain >>> >>> "pending" and even deleting all related objects will not get rid of >>> it and >>> >>> it will remain forever at the bottom of the overview list with an >>> orange >>> >>> circle around it. I can see that the s2i phase completed >>> successfully, the >>> >>> replicationcontroller duly created the pod which was assigned a >>> node, as is >>> >>> shown in the logs: >>> >>> >>> >>> >>> >>> 9:53:18 PM intrinsic-pds-1-7fohj Pod Scheduled >>> >>> Successfully assigned intrinsic-pds-1-7fohj to apps.intrinsic.world >>> >>> 9:53:18 PM intrinsic-pds-1 ReplicationController >>> SuccessfulCreate >>> >>> Created pod: intrinsic-pds-1-7fohj >>> >>> 9:53:15 PM intrinsic-pds-1-deploy Pod Scheduled >>> >>> Successfully assigned >>> >>> i >>> >>> ntrinsic-pds-1-deploy to apps.intrinsic.world >>> >>> >>> >>> The deployment, which will be forever "running" seems to be stuck >>> saying >>> >>> the following: >>> >>> >>> >>> >>> >>> I0218 20:52:12.846055 1 deployer.go:196] Deploying >>> >>> intrinsic-dev/intrinsic-pds-1 for the first time (replicas: 1) >>> >>> I0218 20:52:12.848446 1 recreate.go:105] Scaling >>> >>> intrinsic-dev/intrinsic-pds-1 to 1 before performing acceptance check >>> >>> I0218 20:52:14.909059 1 recreate.go:110] Performing acceptance check >>> of >>> >>> intrinsic-dev/intrinsic-pds-1 >>> >>> I0218 20:52:14.909455 1 lifecycle.go:379] Waiting 600 seconds for >>> pods >>> >>> owned by deployment "intrinsic-dev/intrinsic-pds-1" to become ready >>> >>> (checking every 1 seconds; 0 pods previously accepted) >>> >>> >>> >>> Other than by destroying the entire project (that works), how can I >>> get >>> >>> rid of these buggy pods and more importantly, how can I debug what's >>> >>> affecting my deployments? >>> >> >>> >> >>> >> The deployment is waiting up to 10 minutes to verify that the newly >>> deployed >>> >> version's first pod is ready before progressing. Do you have >>> >> >>> >> any livenessProbe or readinessProbe defined on the pod template >>> inside your >>> >> deploymentConfig? The output of "oc get dc/intrinsic-pds -o yaml" >>> would be >>> >> helpful. >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> users mailing list >>> >> [email protected] >>> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> >> >>> >>> >> >> > >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
