Re: Deploying router

[Clayton Coleman]

On Oct 24, 2016, at 8:25 PM, Sachin Vaidya  wrote:

Hi,
   I tried to deply router in "--host-network=false" mode.
#sudo oadm router router-test  --service-account=router --host-network=false

1) See 2 containers created where one of the Pods remains in
"ContainerCreating" state for long.

[centos@origin-master ~]$ sudo oc get pods
NAME   READY STATUS  RESTARTS   AGE
router-test-1-1rhub0/1   ContainerCreating   0  2m
router-test-1-deploy   1/1   Running 0  2m

2) Also container log on slave node indicates following:
[centos@origin-node-0 /]$ sudo docker logs -f 75c4c2b6d280
--> Scaling router-test-1 to 1
--> Waiting up to 10m0s for pods in deployment router-test-1 to become ready

3) after 10 min, container errors out and deploy Pod transitions to "Error"
state.

error: update acceptor rejected router-test-1: pods for deployment
"router-test-1" took longer than 600 seconds to become ready

[centos@origin-master ~]$ sudo oc get pods
NAME   READY STATUSRESTARTS   AGE
router-test-1-deploy   0/1   Error 0  41m

-> How do I debug this problem? I rsh'ed into the deploy Pod
(router-test-1-deploy)
 and it can reach "kubernetes" service over 443. Have created a router
service
 account before starting router.


This is the pod that orchestrated the deployment

-->  What is the other Pod (router-test-1-1rhub) for. I don't see any
container
  running on slave for this Pod.


This is pod that starts the router software.

Often this can be caused by security issues - run "oc get events" to see
whether there was a problem pulling the image or starting the pod


Thanks
Sachin

--
[centos@origin-master ~]$ sudo oc version
oc v1.3.0
kubernetes v1.3.0+52492b4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://origin-master:8443
openshift v1.3.0
kubernetes v1.3.0+52492b4

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Metric are visible in tab but not on the left side

[Miloslav Vlach]

 curl -i -H "Hawkular-Tenant:admin-prod" -H "Authorization: Bearer ***"
https://hawkular-metrics.rohlik.cz/hawkular/metrics/metrics/stats/query -H
"Content-type: application/json"

HTTP/1.1 405 Method Not Allowed

X-Powered-By: Undertow/1

Server: WildFly/10

Content-Type: application/json

Content-Length: 93

Date: Mon, 24 Oct 2016 17:50:23 GMT

Set-Cookie:
0c90df416451b6e4cbf092da0788a52a=1c56cbcbf14aa6152d9cc3b575ef7ea9; path=/;
HttpOnly


{"errorMsg":"RESTEASY003650: No resource method found for GET, return 405
with Allow header"}


Dne 24. října 2016 v 19:40:03, Miloslav Vlach (miloslav.vl...@rohlik.cz)
napsal/a:

Hi, I have no ads blocker.

The second question I answer later.

Thanks Mila


Dne 24. října 2016 v 19:12:10, Sam Padgett (spadg...@redhat.com) napsal/a:

Can you check the contents of requests to this path?

  /hawkular/metrics/metrics/stats/query


Also confirming again that you don't have an ad blocker for your browser.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Metric are visible in tab but not on the left side

[Sam Padgett]

Can you check the contents of requests to this path?

  /hawkular/metrics/metrics/stats/query


Also confirming again that you don't have an ad blocker for your browser.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Why I don't have debug information in DockerRegistry logs?

[Philippe Lafoucrière]

See: https://github.com/openshift/openshift-ansible/issues/2648
The registry is not logging anything because the ssl handshake failed.
​
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: HELP - Image pull back off

[Scott Dodson]

https://github.com/openshift/openshift-ansible/issues/2648

On Mon, Oct 24, 2016 at 8:57 AM, Philippe Lafoucrière
 wrote:
> For the record, I'm pretty sure that's the issue blocking us from upgrading
> to 1.3.X (the symptoms are exactly the same + this issue
> https://github.com/openshift/origin/issues/11164).
>
> We're using ansible to upgrade, and this change is part of it (yes, we
> should run ansible more often).

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Metric are visible in tab but not on the left side

[Jessica Forrester]

Do you see any errors in your network tab with it trying to make requests
to hawkular?  If it's working in the tab it should work on the overview,
unless you have set the flag to disable overview metrics through an
extension:   window.OPENSHIFT_CONSTANTS.DISABLE_OVERVIEW_METRICS = true

On Sun, Oct 23, 2016 at 3:21 AM, Miloslav Vlach 
wrote:

> Hi,
>
> I can see the metrics on the left side aside the pod information.
>
> but the metrics are available in the pod detail on the tab metrics.
>
>
>
> Knows somebody why it is not displayed ? In this example there are metrics
> started half hour before now, but this didn’t works even if the duration of
> metrics was more and more longer.
>
> Thanks Mila
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Metric are visible in tab but not on the left side

[Sam Padgett]

Hi, Mila. Is Hawkular using a self-signed certificate? If so, try
refreshing the page after accepting the certificate.

Are you are using an ad blocker? If so, try disabling it for the web
console. The overview metrics URLs we use are blocked by some ad blockers
unfortunately.

If neither of these help, it's possible that metrics have been disabled on
the overview using the window.OPENSHIFT_CONSTANTS.DISABLE_OVERVIEW_METRICS
setting.

Hope this helps,
Sam

On Sun, Oct 23, 2016 at 3:21 AM, Miloslav Vlach 
wrote:

> Hi,
>
> I can see the metrics on the left side aside the pod information.
>
> but the metrics are available in the pod detail on the tab metrics.
>
>
>
> Knows somebody why it is not displayed ? In this example there are metrics
> started half hour before now, but this didn’t works even if the duration of
> metrics was more and more longer.
>
> Thanks Mila
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: HELP - Image pull back off

[Philippe Lafoucrière]

For the record, I'm pretty sure that's the issue blocking us from upgrading
to 1.3.X (the symptoms are exactly the same + this issue
https://github.com/openshift/origin/issues/11164).

We're using ansible to upgrade, and this change is part of it (yes, we
should run ansible more often).
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: HELP - Image pull back off

[David Eads]

Adding Scott.

On Sun, Oct 23, 2016 at 9:00 AM, Philippe Lafoucrière <
philippe.lafoucri...@tech-angels.com> wrote:

> Looks like the problem comes from https://github.com/
> openshift/openshift-ansible/pull/2411/files
> Where the registry is considered as secure, but it still listen using http
> only.
>
> This folder shouldn't be empty if I understand correctly:
>
> -bash-4.2# ls -l /etc/docker/certs.d/
> total 0
>
> ​
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: pipeline deployment keeps re-deploying over and over again

[Michail Kargakis]

One more thing, I cannot see latestVersion in the status of your DC? Is
that also 128? Can you also post some of the last RCs too? I am not
familiar with what the Jenkins plugin is updating on the DC.
ccing Gabe and Ben who may know more.

On Mon, Oct 24, 2016 at 11:40 AM, Miklos Balazs  wrote:

> Hi Michail,
>
> Yes, that's how I have removed it. I wanted to remove it because I was
> suspecting that the continuous re-deployments occur because of the config
> change trigger (the jenkins sync plugin is continously updating the DC, and
> these updates are causing the deployment because of the trigger). And after
> removing it and exporting the DC I can see that the ConfigChange trigger
> has indeed been removed. But as soon as I start the pipeline and it reaches
> the deployment phase, the config change trigger is back.
>
> I will open an issue about this as you requested.
>
> Regards,
> Miklós
>
> On Mon, Oct 24, 2016 at 11:31 AM, Michail Kargakis 
> wrote:
>
>> If you don't want to use a CC trigger, do not remove the field but set it
>> as an empty array = [] (similar to the triggers field in the BC)
>>
>> https://docs.openshift.org/latest/dev_guide/deployments.html#triggers
>>
>> Can you open an issue on Github about the behavior you see? I will look
>> at it later today. Thanks.
>>
>> On Mon, Oct 24, 2016 at 11:05 AM, Miklos Balazs 
>> wrote:
>>
>>> Hi Michail,
>>>
>>> Sure. I'm running origin-1.3.0 from the CentOS RPMs. Here is my DC:
>>>
>>> apiVersion: v1
>>> kind: DeploymentConfig
>>> metadata:
>>>   annotations:
>>> openshift.io/generated-by: OpenShiftWebConsole
>>>   creationTimestamp: null
>>>   generation: 128
>>>   labels:
>>> app: myapp
>>>   name: myapp
>>> spec:
>>>   replicas: 1
>>>   selector:
>>> deploymentconfig: myapp
>>>   strategy:
>>> resources: {}
>>> rollingParams:
>>>   intervalSeconds: 1
>>>   maxSurge: 25%
>>>   maxUnavailable: 25%
>>>   timeoutSeconds: 600
>>>   updatePeriodSeconds: 1
>>> type: Rolling
>>>   template:
>>> metadata:
>>>   creationTimestamp: null
>>>   labels:
>>> app: myapp
>>> deploymentconfig: myapp
>>> spec:
>>>   containers:
>>>   - image: 172.30.232.245:5000/pipeline-build/myapp:latest
>>> imagePullPolicy: Always
>>> name: myapp
>>> ports:
>>> - containerPort: 8080
>>>   protocol: TCP
>>> resources: {}
>>> terminationMessagePath: /dev/termination-log
>>>   dnsPolicy: ClusterFirst
>>>   restartPolicy: Always
>>>   securityContext: {}
>>>   terminationGracePeriodSeconds: 30
>>>   test: false
>>>   triggers:
>>>   - type: ConfigChange
>>> status:
>>>   availableReplicas: 1
>>>   observedGeneration: 128
>>>   replicas: 1
>>>   updatedReplicas: 1
>>>
>>> The funny thing is that if I remove the ConfigChange trigger, it gets
>>> added back as soon as I start the pipeline and it reaches the deploy phase
>>> (but not sooner).
>>>
>>> This is my pipeline BC:
>>>
>>> apiVersion: v1
>>> kind: BuildConfig
>>> metadata:
>>>   annotations:
>>> pipeline.alpha.openshift.io/uses: '[{"name": "myapp", "namespace":
>>> "", "kind":
>>>   "DeploymentConfig"}]'
>>>   creationTimestamp: null
>>>   labels:
>>> name: myfirstpipeline
>>>   name: myfirstpipeline
>>> spec:
>>>   output: {}
>>>   postCommit: {}
>>>   resources: {}
>>>   runPolicy: Serial
>>>   source:
>>> type: None
>>>   strategy:
>>> jenkinsPipelineStrategy:
>>>   jenkinsfile: |-
>>> node('maven') {
>>> stage 'build'
>>> openshiftBuild(buildConfig: 'myapp', showBuildLogs: 'true')
>>> stage 'deploy'
>>> openshiftDeploy(deploymentConfig: 'myapp')
>>> openshiftScale(deploymentConfig: 'myapp',replicaCount: '2')
>>> }
>>> type: JenkinsPipeline
>>>   triggers: []
>>> status:
>>>   lastVersion: 0
>>>
>>> Regards,
>>> Miklos
>>>
>>> On Mon, Oct 24, 2016 at 10:15 AM, Michail Kargakis 
>>> wrote:
>>>
 What version of OpenShift are you running? Can you post your DC?

 On Sat, Oct 22, 2016 at 6:33 PM, Miklos Balazs 
 wrote:

> Hi Everyone,
>
> I am trying to set up a build pipeline by following the tutorial on
> the OpenShift blog site  (https://blog.openshift.com/c
> reate-build-pipelines-openshift-3-3/), but I couldn't manage to set
> it up properly, not even the simple pipeline from Part 1.
>
> The first problem is I encountered was that if I create the
> application by disabling the config change and image change triggers on 
> the
> deployment (as shown in the video), then the deployment will fail, because
> the DC created by the web console has the value "myphp:latest" under
> "spec.template.spec.containers[0].image". Without an image change
> trigger, this value won't get updated to point to the specific image 
> 

Re: pipeline deployment keeps re-deploying over and over again

[Miklos Balazs]

Hi Michail,

Yes, that's how I have removed it. I wanted to remove it because I was
suspecting that the continuous re-deployments occur because of the config
change trigger (the jenkins sync plugin is continously updating the DC, and
these updates are causing the deployment because of the trigger). And after
removing it and exporting the DC I can see that the ConfigChange trigger
has indeed been removed. But as soon as I start the pipeline and it reaches
the deployment phase, the config change trigger is back.

I will open an issue about this as you requested.

Regards,
Miklós

On Mon, Oct 24, 2016 at 11:31 AM, Michail Kargakis 
wrote:

> If you don't want to use a CC trigger, do not remove the field but set it
> as an empty array = [] (similar to the triggers field in the BC)
>
> https://docs.openshift.org/latest/dev_guide/deployments.html#triggers
>
> Can you open an issue on Github about the behavior you see? I will look at
> it later today. Thanks.
>
> On Mon, Oct 24, 2016 at 11:05 AM, Miklos Balazs  wrote:
>
>> Hi Michail,
>>
>> Sure. I'm running origin-1.3.0 from the CentOS RPMs. Here is my DC:
>>
>> apiVersion: v1
>> kind: DeploymentConfig
>> metadata:
>>   annotations:
>> openshift.io/generated-by: OpenShiftWebConsole
>>   creationTimestamp: null
>>   generation: 128
>>   labels:
>> app: myapp
>>   name: myapp
>> spec:
>>   replicas: 1
>>   selector:
>> deploymentconfig: myapp
>>   strategy:
>> resources: {}
>> rollingParams:
>>   intervalSeconds: 1
>>   maxSurge: 25%
>>   maxUnavailable: 25%
>>   timeoutSeconds: 600
>>   updatePeriodSeconds: 1
>> type: Rolling
>>   template:
>> metadata:
>>   creationTimestamp: null
>>   labels:
>> app: myapp
>> deploymentconfig: myapp
>> spec:
>>   containers:
>>   - image: 172.30.232.245:5000/pipeline-build/myapp:latest
>> imagePullPolicy: Always
>> name: myapp
>> ports:
>> - containerPort: 8080
>>   protocol: TCP
>> resources: {}
>> terminationMessagePath: /dev/termination-log
>>   dnsPolicy: ClusterFirst
>>   restartPolicy: Always
>>   securityContext: {}
>>   terminationGracePeriodSeconds: 30
>>   test: false
>>   triggers:
>>   - type: ConfigChange
>> status:
>>   availableReplicas: 1
>>   observedGeneration: 128
>>   replicas: 1
>>   updatedReplicas: 1
>>
>> The funny thing is that if I remove the ConfigChange trigger, it gets
>> added back as soon as I start the pipeline and it reaches the deploy phase
>> (but not sooner).
>>
>> This is my pipeline BC:
>>
>> apiVersion: v1
>> kind: BuildConfig
>> metadata:
>>   annotations:
>> pipeline.alpha.openshift.io/uses: '[{"name": "myapp", "namespace":
>> "", "kind":
>>   "DeploymentConfig"}]'
>>   creationTimestamp: null
>>   labels:
>> name: myfirstpipeline
>>   name: myfirstpipeline
>> spec:
>>   output: {}
>>   postCommit: {}
>>   resources: {}
>>   runPolicy: Serial
>>   source:
>> type: None
>>   strategy:
>> jenkinsPipelineStrategy:
>>   jenkinsfile: |-
>> node('maven') {
>> stage 'build'
>> openshiftBuild(buildConfig: 'myapp', showBuildLogs: 'true')
>> stage 'deploy'
>> openshiftDeploy(deploymentConfig: 'myapp')
>> openshiftScale(deploymentConfig: 'myapp',replicaCount: '2')
>> }
>> type: JenkinsPipeline
>>   triggers: []
>> status:
>>   lastVersion: 0
>>
>> Regards,
>> Miklos
>>
>> On Mon, Oct 24, 2016 at 10:15 AM, Michail Kargakis 
>> wrote:
>>
>>> What version of OpenShift are you running? Can you post your DC?
>>>
>>> On Sat, Oct 22, 2016 at 6:33 PM, Miklos Balazs 
>>> wrote:
>>>
 Hi Everyone,

 I am trying to set up a build pipeline by following the tutorial on the
 OpenShift blog site  (https://blog.openshift.com/c
 reate-build-pipelines-openshift-3-3/), but I couldn't manage to set it
 up properly, not even the simple pipeline from Part 1.

 The first problem is I encountered was that if I create the application
 by disabling the config change and image change triggers on the deployment
 (as shown in the video), then the deployment will fail, because the DC
 created by the web console has the value "myphp:latest" under
 "spec.template.spec.containers[0].image". Without an image change
 trigger, this value won't get updated to point to the specific image stream
 in the internal registry.

 But I could overcome this by setting the proper value in the DC, so it
 points to the image stream. This way the deployment should work properly,
 but then I hit another problem: when I start the pipeline, the build phase
 succeeds, and then at the deployment phase it keeps on deploying the
 application over and over again. 10 minutes and about 30 deployments later
 the deployment phase of the pipeline times out, and the 

Re: pipeline deployment keeps re-deploying over and over again

[Michail Kargakis]

If you don't want to use a CC trigger, do not remove the field but set it
as an empty array = [] (similar to the triggers field in the BC)

https://docs.openshift.org/latest/dev_guide/deployments.html#triggers

Can you open an issue on Github about the behavior you see? I will look at
it later today. Thanks.

On Mon, Oct 24, 2016 at 11:05 AM, Miklos Balazs  wrote:

> Hi Michail,
>
> Sure. I'm running origin-1.3.0 from the CentOS RPMs. Here is my DC:
>
> apiVersion: v1
> kind: DeploymentConfig
> metadata:
>   annotations:
> openshift.io/generated-by: OpenShiftWebConsole
>   creationTimestamp: null
>   generation: 128
>   labels:
> app: myapp
>   name: myapp
> spec:
>   replicas: 1
>   selector:
> deploymentconfig: myapp
>   strategy:
> resources: {}
> rollingParams:
>   intervalSeconds: 1
>   maxSurge: 25%
>   maxUnavailable: 25%
>   timeoutSeconds: 600
>   updatePeriodSeconds: 1
> type: Rolling
>   template:
> metadata:
>   creationTimestamp: null
>   labels:
> app: myapp
> deploymentconfig: myapp
> spec:
>   containers:
>   - image: 172.30.232.245:5000/pipeline-build/myapp:latest
> imagePullPolicy: Always
> name: myapp
> ports:
> - containerPort: 8080
>   protocol: TCP
> resources: {}
> terminationMessagePath: /dev/termination-log
>   dnsPolicy: ClusterFirst
>   restartPolicy: Always
>   securityContext: {}
>   terminationGracePeriodSeconds: 30
>   test: false
>   triggers:
>   - type: ConfigChange
> status:
>   availableReplicas: 1
>   observedGeneration: 128
>   replicas: 1
>   updatedReplicas: 1
>
> The funny thing is that if I remove the ConfigChange trigger, it gets
> added back as soon as I start the pipeline and it reaches the deploy phase
> (but not sooner).
>
> This is my pipeline BC:
>
> apiVersion: v1
> kind: BuildConfig
> metadata:
>   annotations:
> pipeline.alpha.openshift.io/uses: '[{"name": "myapp", "namespace":
> "", "kind":
>   "DeploymentConfig"}]'
>   creationTimestamp: null
>   labels:
> name: myfirstpipeline
>   name: myfirstpipeline
> spec:
>   output: {}
>   postCommit: {}
>   resources: {}
>   runPolicy: Serial
>   source:
> type: None
>   strategy:
> jenkinsPipelineStrategy:
>   jenkinsfile: |-
> node('maven') {
> stage 'build'
> openshiftBuild(buildConfig: 'myapp', showBuildLogs: 'true')
> stage 'deploy'
> openshiftDeploy(deploymentConfig: 'myapp')
> openshiftScale(deploymentConfig: 'myapp',replicaCount: '2')
> }
> type: JenkinsPipeline
>   triggers: []
> status:
>   lastVersion: 0
>
> Regards,
> Miklos
>
> On Mon, Oct 24, 2016 at 10:15 AM, Michail Kargakis 
> wrote:
>
>> What version of OpenShift are you running? Can you post your DC?
>>
>> On Sat, Oct 22, 2016 at 6:33 PM, Miklos Balazs  wrote:
>>
>>> Hi Everyone,
>>>
>>> I am trying to set up a build pipeline by following the tutorial on the
>>> OpenShift blog site  (https://blog.openshift.com/c
>>> reate-build-pipelines-openshift-3-3/), but I couldn't manage to set it
>>> up properly, not even the simple pipeline from Part 1.
>>>
>>> The first problem is I encountered was that if I create the application
>>> by disabling the config change and image change triggers on the deployment
>>> (as shown in the video), then the deployment will fail, because the DC
>>> created by the web console has the value "myphp:latest" under
>>> "spec.template.spec.containers[0].image". Without an image change
>>> trigger, this value won't get updated to point to the specific image stream
>>> in the internal registry.
>>>
>>> But I could overcome this by setting the proper value in the DC, so it
>>> points to the image stream. This way the deployment should work properly,
>>> but then I hit another problem: when I start the pipeline, the build phase
>>> succeeds, and then at the deployment phase it keeps on deploying the
>>> application over and over again. 10 minutes and about 30 deployments later
>>> the deployment phase of the pipeline times out, and the build pipeline
>>> stops with an error. At this point, the continous re-deployment stops and I
>>> end up with a working deployment of my app.
>>>
>>> What I could figure out is that somehow a ConfigChange trigger got added
>>> to the DC. I think that this might have something to do with the continuous
>>> re-deployments: possibly something is updating the DC during the deployment
>>> phase of the pipeline, and this causes it to keep deploying over and over
>>> again (there is a "openshift.io/deployment.status-reason: caused by a
>>> config change" annotation on the RCs). If I remove the ConfigChange trigger
>>> from the DC, it gets added again as soon as I start the pipeline.
>>>
>>> Could someone please help me with this? Am I doing something wrong or
>>> maybe something's broken with my setup?
>>>