Re: pipeline validation failures

[Just Marvin]

Hi,

This appears to be a documentation bug. If I follow the
release-tech-preview-1 branch of the git repo for the example, the
instructions associated with that work correctly with the openshift
pipelines operator included in the latest version of codeready containers.

Regards,
Marvin

On Wed, Sep 16, 2020 at 4:15 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> I'm following the instructions in
> https://docs.openshift.com/container-platform/4.5/pipelines/creating-applications-with-cicd-pipelines.html#running-a-pipeline_creating-applications-with-cicd-pipelines
>  ,
> and things break on step 1 of "Running a pipeline". Here is what I get:
>
> [zaphod@oc6010654212 vote-api]$ tkn pipelinerun list
> NAME STARTEDDURATIONSTATUS
> build-and-deploy-run-pmncm   1 minute ago   0 seconds
> Failed(PipelineValidationFailed)
> [zaphod@oc6010654212 vote-api]$ tkn pipelinerun logs
> build-and-deploy-run-86bjs -f -n pipelines-tutorial
> invalid input params: didn't need these params but they were provided
> anyway: [IMAGE]
> [zaphod@oc6010654212 vote-api]$
>
> But the parameter in question is there in the pipeline, as can be seen
> below:
>
> [image: image.png]
>
>  How do I fix / investigate this?
>
> Thanks,
> Marvin
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

pipeline validation failures

[Just Marvin]

Hi,

I'm following the instructions in
https://docs.openshift.com/container-platform/4.5/pipelines/creating-applications-with-cicd-pipelines.html#running-a-pipeline_creating-applications-with-cicd-pipelines
,
and things break on step 1 of "Running a pipeline". Here is what I get:

[zaphod@oc6010654212 vote-api]$ tkn pipelinerun list
NAME STARTEDDURATIONSTATUS
build-and-deploy-run-pmncm   1 minute ago   0 seconds
Failed(PipelineValidationFailed)
[zaphod@oc6010654212 vote-api]$ tkn pipelinerun logs
build-and-deploy-run-86bjs -f -n pipelines-tutorial
invalid input params: didn't need these params but they were provided
anyway: [IMAGE]
[zaphod@oc6010654212 vote-api]$

But the parameter in question is there in the pipeline, as can be seen
below:

[image: image.png]

 How do I fix / investigate this?

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

Re: when is a "secrets link" needed?

[Just Marvin]

Clayton,

Thanks for the response. "no longer required" as in this was a change
made recently? What version of OpenShift was this change made effective in?

Thanks,
Marvin

On Thu, Sep 10, 2020 at 10:02 AM Clayton Coleman 
wrote:

> Link is no longer required unless you want pods with that service account
> to use a pull secret automatically.  Import isn't related to a service
> account, so it uses all pull secrets in the namespace.
>
> On Thu, Sep 10, 2020 at 9:25 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> I've observed that for an import-image to work, I don't need to link
>> my pull secret to a service account. I just need to create the secret. Yet,
>> there are other times when the link is absolutely required. (1) if the
>> import-image works without a link to a service account, it must be working
>> without using a service account. How does it know which secret to use for
>> pulling an image from an external registry? (2) If a secret "auto find" is
>> really possible, whats the point of this "link" step in circumstances where
>> it is needed today?
>>
>> Regards,
>> Marvin
>> ___
>> 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

when is a "secrets link" needed?

[Just Marvin]

Hi,

I've observed that for an import-image to work, I don't need to link my
pull secret to a service account. I just need to create the secret. Yet,
there are other times when the link is absolutely required. (1) if the
import-image works without a link to a service account, it must be working
without using a service account. How does it know which secret to use for
pulling an image from an external registry? (2) If a secret "auto find" is
really possible, whats the point of this "link" step in circumstances where
it is needed today?

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

Re: healthchecks and Istio

[Just Marvin]

Hi,

Eventually figured this out via pointers from istio's slack community.
Was able to track down the required pod annotation that I needed from
https://istio.io/v1.4/docs/ops/configuration/mesh/app-health-check/ . Given
that I didn't get a response from anyone on this list, I'm wondering if I
asked in the right place. Is there a better mailing list for Red Hat
Service Mesh questions?

Regards,
Marvin

On Fri, Sep 4, 2020 at 9:40 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> Found this: https://github.com/istio/istio/issues/2628 . Given that
> this was from 2018, I went and checked the current istio FAQ and didn't see
> it listed there. Of course, current istio isn't what is bundled into the
> Red Hat Service Mesh, so I'm not sure what the status is. Is this still the
> recommendation for liveness and readiness probes in the presence of istio?
>
> Regards,
> Marvin
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

healthchecks and Istio

[Just Marvin]

Hi,

Found this: https://github.com/istio/istio/issues/2628 . Given that
this was from 2018, I went and checked the current istio FAQ and didn't see
it listed there. Of course, current istio isn't what is bundled into the
Red Hat Service Mesh, so I'm not sure what the status is. Is this still the
recommendation for liveness and readiness probes in the presence of istio?

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

change in new-app behavior

[Just Marvin]

Hi,

When I use an oc v4.3 client against a v4.3 server, I get:

[zaphod@oc3027208274 tmp]$ oc new-app --name=special-sm
kstephe/security-manager
--> Found image 8031044 (5 days old) in image stream
"kstephe/security-manager" under tag "latest" for "kstephe/security-manager"

* This image will be deployed in deployment config "special-sm"
* The image does not expose any ports - if you want to load balance or
send traffic to this component
  you will need to create a service with 'oc expose dc/special-sm
--port=[port]' later
* WARNING: Image "kstephe/security-manager:latest" runs as the 'root'
user which may not be permitted by your cluster administrator

--> Creating resources ...
imagestreamtag.image.openshift.io "special-sm:latest" created
deploymentconfig.apps.openshift.io "special-sm" created
--> Success
Run 'oc status' to view your app.
[zaphod@oc3027208274 tmp]$

..which creates a deployment config, as expected. However, when I use
an oc v4.5 client against the same server, I get:

[zaphod@oc6010654212 ~]$ oc new-app --name=special-sm
kstephe/security-manager
--> Found image 8031044 (6 days old) in image stream
"kstephe/security-manager" under tag "latest" for "kstephe/security-manager"


--> Creating resources ...
imagestreamtag.image.openshift.io "special-sm:latest" created
deployment.apps "special-sm" created
--> Success
Run 'oc status' to view your app.

.which is creating a deployment. Why this change in behavior? Is there
a shift in policy as of v4.5?

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

bound services tokens - how to configure

[Just Marvin]

Hi,

 I'm looking at the documentation for bound service tokens
,
and while I'm clear on how the pod itself needs to be configured for using
the token, it's not clear to me how the integration to the IAM service
itself is defined. Something, somewhere has to specify where the IAM
service is ( spec.serviceAccountIssuer? ), or what the client id and client
secrets are (if oauth is being used). Where is that done?

Is this feature intended to work with any Oauth / OIDC provider?

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

trouble with port forwarding

[Just Marvin]

Hi,

I'm port forwarding to a redis server running within my openshift
cluster:

[zaphod@oc3027208274 ~]$ oc port-forward redis-1-s28xs 6379
Forwarding from 127.0.0.1:6379 -> 6379
Forwarding from [::1]:6379 -> 6379

I also have a redis-cli built in a container which I'm running on my
machine (where I'm doing the port-forwarding). However, starting up this
container is proving to be impossible:

[zaphod@oc3027208274 redis-cli]$ sudo podman run --name redis-cli -p
6379:6379 localhost/redis-cli
Error: cannot listen on the TCP port: listen tcp4 :6379: bind: address
already in use
[zaphod@oc3027208274 redis-cli]

Whats the right way to get the redis-cli in my container communicate
with the redis server running remotely on openshift?

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

Re: scaleTargetRef for autoscaling

[Just Marvin]

Joel,

 That clears it up.

Thanks,
Marvin

On Thu, Jun 25, 2020 at 2:56 AM Joel Pearson 
wrote:

> Hi Marvin,
>
> I presume you are using a deployment config?
>
> If so, doesn't a deployment config create a new replication controller
> every time you do a deploy?
>
> Which means you'd lose your scaling every deploy, so I think if you are
> using deployment configs, then you'd want to reference those, rather than
> the replication controllers that it automatically creates for you.
>
> Cheers,
>
> Joel
>
> On Wed, 17 Jun 2020 at 20:42, Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> The docs say that the scaleTargetRef can point to either the
>> deployment config or the replication controller. Is there a difference in
>> autoscaling behavior if I pick one over the other?
>>
>> Regards,
>> Marvin
>> ___
>> 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

scaleTargetRef for autoscaling

[Just Marvin]

Hi,

The docs say that the scaleTargetRef can point to either the deployment
config or the replication controller. Is there a difference in autoscaling
behavior if I pick one over the other?

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

cordoning and tainting - do they apply to openshift pods?

[Just Marvin]

Hi,

I'm working with a cluster which has three nodes - which each share the
master and worker roles (obviously a demo, not a production cluster). We
are trying to demonstrate the cluster response to node failure events, and
as part of this work, we are also applying cordon and uncordon operations
(and may even set up taints) so that we can demonstrate some of the more
complicated use cases. If I cordon off a node, will it stop the scheduler
from placing openshift owned pods on that node as well, or will the
scheduler ignore taints and cordons when it does its work? I'm trying to
figure out if in this configuration, I may end up breaking the cluster by
making changes to where the openshift pods can be placed.

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

Re: image registry problems

[Just Marvin]

Oleg,

Problem is no longer present so I don't know if sending you the yamls
will make a difference. Around the time that I had posted my request for
help, I had tried bouncing the image registry by scaling the pod down to 0
and scaling it back up to 1, but that didn't work. But a few hours later,
one of the support people did the same thing and service was restored.

I suspect that the problem was caused by me rebooting the node that was
running the single image registry pod. [Why, you ask, would I do such a
thing? Because I'm working on a demo that is trying to showcase how well
OpenShift addresses node failures]. If the problem recurs again, I'll add
in the details you asked for.

Regards,
Marvin

On Thu, Jun 4, 2020 at 10:18 AM Oleg Bulatov  wrote:

> Hi Marvin,
>
> On Thu, Jun 04, 2020 at 08:01:57AM -0400, Just Marvin wrote:
> > I went digging around for clues and found this in the image-registry pod
> logs:
> >
> > [zaphod@oc3027208274 exam]$ oc logs image-registry-5c54f5b447-lg4tx
> > p11-kit: couldn't complete writing file:
> > /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt: Operation not
> > permitted
> > p11-kit: couldn't complete writing file:
> > /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem: Operation not
> > permitted
> > p11-kit: couldn't complete writing file:
> > /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem: Operation not
> > permitted
> > p11-kit: couldn't complete writing file:
> > /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem: Operation not
> > permitted
> > p11-kit: couldn't complete writing file:
> > /etc/pki/ca-trust/extracted/java/cacerts: Operation not permitted
> > [zaphod@oc3027208274 exam]$
>
> The registry pod cannot add CAs to its trust store.
>
> Can you share yamls of config.imageregistry/cluster and
> image.config/cluster? And also the cluster version. I want to reproduce
> it.
>
> > The image registry operator logs show this:
> >
> > [zaphod@oc3027208274 exam]$ oc logs
> > cluster-image-registry-operator-6f78cddbbc-5qcth -c
> > cluster-image-registry-operator | tail
> > I0604 11:51:20.563865  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> > I0604 11:51:20.564105  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> > I0604 11:51:58.508989  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> > I0604 11:52:11.852526  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> > I0604 11:52:11.863955  58 caconfig.go:123] missing the
> > cloud-provider-config configmap: configmap "cloud-provider-config" not
> > found
> > I0604 11:52:11.870390  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> > I0604 11:52:11.877891  58 controller.go:254] event from workqueue
> > successfully processed
> > I0604 11:52:11.885976  58 caconfig.go:123] missing the
> > cloud-provider-config configmap: configmap "cloud-provider-config" not
> > found
> > I0604 11:52:11.902534  58 controller.go:254] event from workqueue
> > successfully processed
> > I0604 11:53:12.869816  58 clusteroperator.go:98] event from
> > workqueue successfully processed
> >
> > Any clues as to what this all means, and any suggestions on how I
> > can recover?
>
> That's OK, all messages are informational (the first letter is I), the
> operator reacts on object changes ("events"). The configmap
> cloud-provider-config is not required for the operator, this notice will
> be removed in 4.5.
>
> Oleg
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

image registry problems

[Just Marvin]

Hi,

I'm encountering pull problems from the internal image registry:

[zaphod@oc3027208274 exam]$ oc logs -f bc/ingest-service-poc
Cloning "g...@github.some.corp:surge-team-irs-mef/ingest-service.git" ...
Commit: 8e51033f0863bae2372dcad6c1fbd9a0dd57ece6 (added postman tests)
Author: 'Somebody Else' <'pay.no.attention@here'>
Date:   Wed Jun 3 16:55:56 2020 -0400
Caching blobs under "/var/cache/blobs".
Warning: Pull failed, retrying in 5s ...
Warning: Pull failed, retrying in 5s ...
Warning: Pull failed, retrying in 5s ...
error: build error: After retrying 2 times, Pull image still failed
due to error: while pulling
"docker://image-registry.openshift-image-registry.svc:5000/openshift/java@sha256:4dc1ae6af9a3efbbd28c1b765faa6fcea3f8eddccd2347ad97713d312f57b511"
as 
"image-registry.openshift-image-registry.svc:5000/openshift/java@sha256:4dc1ae6af9a3efbbd28c1b765faa6fcea3f8eddccd2347ad97713d312f57b511":
Error initializing source
docker://image-registry.openshift-image-registry.svc:5000/openshift/java@sha256:4dc1ae6af9a3efbbd28c1b765faa6fcea3f8eddccd2347ad97713d312f57b511:
error pinging docker registry
image-registry.openshift-image-registry.svc:5000: Get
https://image-registry.openshift-image-registry.svc:5000/v2/
:
dial tcp 172.21.214.79:5000: connect: connection timed out
[zaphod@oc3027208274 exam]$

I went digging around for clues and found this in the image-registry pod logs:

[zaphod@oc3027208274 exam]$ oc logs image-registry-5c54f5b447-lg4tx
p11-kit: couldn't complete writing file:
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt: Operation not
permitted
p11-kit: couldn't complete writing file:
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem: Operation not
permitted
p11-kit: couldn't complete writing file:
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem: Operation not
permitted
p11-kit: couldn't complete writing file:
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem: Operation not
permitted
p11-kit: couldn't complete writing file:
/etc/pki/ca-trust/extracted/java/cacerts: Operation not permitted
[zaphod@oc3027208274 exam]$

The image registry operator logs show this:

[zaphod@oc3027208274 exam]$ oc logs
cluster-image-registry-operator-6f78cddbbc-5qcth -c
cluster-image-registry-operator | tail
I0604 11:51:20.563865  58 clusteroperator.go:98] event from
workqueue successfully processed
I0604 11:51:20.564105  58 clusteroperator.go:98] event from
workqueue successfully processed
I0604 11:51:58.508989  58 clusteroperator.go:98] event from
workqueue successfully processed
I0604 11:52:11.852526  58 clusteroperator.go:98] event from
workqueue successfully processed
I0604 11:52:11.863955  58 caconfig.go:123] missing the
cloud-provider-config configmap: configmap "cloud-provider-config" not
found
I0604 11:52:11.870390  58 clusteroperator.go:98] event from
workqueue successfully processed
I0604 11:52:11.877891  58 controller.go:254] event from workqueue
successfully processed
I0604 11:52:11.885976  58 caconfig.go:123] missing the
cloud-provider-config configmap: configmap "cloud-provider-config" not
found
I0604 11:52:11.902534  58 controller.go:254] event from workqueue
successfully processed
I0604 11:53:12.869816  58 clusteroperator.go:98] event from
workqueue successfully processed

Any clues as to what this all means, and any suggestions on how I
can recover?

Thanks,

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

Re: Not able to see redistribution of workload after node failures

[Just Marvin]

Hi,

Got things working finally. Pod tolerations were the answer. Added this
to the dc, and then things worked right:

"tolerations": [
{
"effect": "NoExecute",
"key": "node.kubernetes.io/not-ready",
"operator": "Exists",
"tolerationSeconds": 30
},
{
"effect": "NoExecute",
"key": "node.kubernetes.io/unreachable",
"operator": "Exists",
        "tolerationSeconds": 30
}
]

Regards,
Marvin

On Fri, May 29, 2020 at 12:00 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
>  Further experiments have shown that if we keep a node down, after
> about 5 - 6 mins of the node being in the NotReady state, the cluster does
> try to terminate the "running" pod, and stand up a new replacement pod. The
> pod being terminated just sits there in the "Terminating" state forever,
> but the new pod does get into the "Running" state. Which is good. However,
> 5+ mins to get to this is too long for us. Is there some knob to turn which
> will allow us to decrease that period of time?
>
> Thanks,
> Marvin
>
> On Fri, May 29, 2020 at 10:32 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> My problem has gotten a little worse.I cordoned off a node,
>> rebooted it, and when the node came back up, I see that the pods have been
>> restarted on the newly rebooted node. This seems like a bug. Any thoughts?
>>
>> Regards,
>> Marvin
>>
>> On Fri, May 29, 2020 at 6:49 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm working on a demonstration of OpenShift where we are trying to
>>> showcase its automatic response to various failure events - a big part of
>>> the demo being how it responds to node failure. I've got three worker
>>> nodes, and a reboot of one happens in < 2 mins. I would expect to see the
>>> pods on the failed / rebooted nodes migrate to the the other two nodes.
>>> Instead, what I see is that even when the machine is down, it takes a while
>>> for OpenShift to detect the failure, and at that point, I see this:
>>>
>>> zaphod@oc3027208274 constants]$ oc get pods -l app=ingest-service-poc
>>> NAME  READY   STATUSRESTARTS   AGE
>>> ingest-service-poc-5656c574df-bbq2v   1/1 Running   0  45h
>>> ingest-service-poc-5656c574df-d4t9l   1/1 Running   0  6d15h
>>> ingest-service-poc-5656c574df-gmlm7   1/1 Running   0  44h
>>> ingest-service-poc-5656c574df-j4rgn   0/1 Error 5  18h
>>> ingest-service-poc-5656c574df-kl8vp   1/1 Running   0  45h
>>> ingest-service-poc-5656c574df-mcvtb   1/1 Running   6  45h
>>> ingest-service-poc-5656c574df-rt24l   1/1 Running   0  45h
>>> ingest-service-poc-5656c574df-w99v6   0/1 Error 5  45h
>>> ingest-service-poc-5656c574df-ztl6h   1/1 Running   0  44h
>>>
>>> It looks like the pods are simply being restarted on the same node
>>> whenever it comes back from the reboot. The pod does not have a liveness or
>>> a readiness probe configured, so this is all driven by events that
>>> kubernetes detects from the node failure. Eventually, the pods are all
>>> restarted and everything is back to the "Running" state.
>>>
>>> Is this the right behavior for the cluster? Are there timeouts /
>>> frequency of checks for node failure etc that we can tune to show a
>>> redistribution of the pods when a node fails?
>>>
>>> To add to my problems, on some instances, after the node failure,
>>> this is the stable state:
>>>
>>> NAME  READY   STATUS
>>> RESTARTS   AGE
>>> ingest-service-poc-5656c574df-bbq2v   1/1 Running0
>>>45h
>>> ingest-service-poc-5656c574df-d4t9l   1/1 Running0
>>>6d15h
>>> ingest-service-poc-5656c574df-gmlm7   1/1 Running0
>>>45h
>>> ingest-service-poc-5656c574df-j4rgn   0/1 CrashLoopBackOff   13
>>> 18h
>>> ingest-ser

Re: Not able to see redistribution of workload after node failures

[Just Marvin]

Hi,

 Further experiments have shown that if we keep a node down, after
about 5 - 6 mins of the node being in the NotReady state, the cluster does
try to terminate the "running" pod, and stand up a new replacement pod. The
pod being terminated just sits there in the "Terminating" state forever,
but the new pod does get into the "Running" state. Which is good. However,
5+ mins to get to this is too long for us. Is there some knob to turn which
will allow us to decrease that period of time?

Thanks,
Marvin

On Fri, May 29, 2020 at 10:32 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> My problem has gotten a little worse.I cordoned off a node,
> rebooted it, and when the node came back up, I see that the pods have been
> restarted on the newly rebooted node. This seems like a bug. Any thoughts?
>
> Regards,
> Marvin
>
> On Fri, May 29, 2020 at 6:49 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm working on a demonstration of OpenShift where we are trying to
>> showcase its automatic response to various failure events - a big part of
>> the demo being how it responds to node failure. I've got three worker
>> nodes, and a reboot of one happens in < 2 mins. I would expect to see the
>> pods on the failed / rebooted nodes migrate to the the other two nodes.
>> Instead, what I see is that even when the machine is down, it takes a while
>> for OpenShift to detect the failure, and at that point, I see this:
>>
>> zaphod@oc3027208274 constants]$ oc get pods -l app=ingest-service-poc
>> NAME  READY   STATUSRESTARTS   AGE
>> ingest-service-poc-5656c574df-bbq2v   1/1 Running   0  45h
>> ingest-service-poc-5656c574df-d4t9l   1/1 Running   0  6d15h
>> ingest-service-poc-5656c574df-gmlm7   1/1 Running   0  44h
>> ingest-service-poc-5656c574df-j4rgn   0/1 Error 5  18h
>> ingest-service-poc-5656c574df-kl8vp   1/1 Running   0  45h
>> ingest-service-poc-5656c574df-mcvtb   1/1 Running   6  45h
>> ingest-service-poc-5656c574df-rt24l   1/1 Running   0  45h
>> ingest-service-poc-5656c574df-w99v6   0/1 Error 5  45h
>> ingest-service-poc-5656c574df-ztl6h   1/1 Running   0  44h
>>
>> It looks like the pods are simply being restarted on the same node
>> whenever it comes back from the reboot. The pod does not have a liveness or
>> a readiness probe configured, so this is all driven by events that
>> kubernetes detects from the node failure. Eventually, the pods are all
>> restarted and everything is back to the "Running" state.
>>
>> Is this the right behavior for the cluster? Are there timeouts /
>> frequency of checks for node failure etc that we can tune to show a
>> redistribution of the pods when a node fails?
>>
>> To add to my problems, on some instances, after the node failure,
>> this is the stable state:
>>
>> NAME  READY   STATUS RESTARTS
>>   AGE
>> ingest-service-poc-5656c574df-bbq2v   1/1 Running0
>>45h
>> ingest-service-poc-5656c574df-d4t9l   1/1 Running0
>>6d15h
>> ingest-service-poc-5656c574df-gmlm7   1/1 Running0
>>45h
>> ingest-service-poc-5656c574df-j4rgn   0/1 CrashLoopBackOff   13
>>   18h
>> ingest-service-poc-5656c574df-kl8vp   1/1 Running0
>>45h
>> ingest-service-poc-5656c574df-mcvtb   0/1 CrashLoopBackOff   13
>>   45h
>> ingest-service-poc-5656c574df-rt24l   1/1 Running0
>>45h
>> ingest-service-poc-5656c574df-w99v6   0/1 CrashLoopBackOff   11
>>   45h
>> ingest-service-poc-5656c574df-ztl6h   1/1 Running0
>>45h
>>
>> Not sure why this happens, and how we can avoid getting here. Some
>> data to go with this:
>>
>> [zaphod@oc3027208274 constants]$ oc get events | grep
>> ingest-service-poc-5656c574df-j4rgn
>> 12m NormalTaintManagerEviction
>> pod/ingest-service-poc-5656c574df-j4rgn   Cancelling deletion of Pod
>> irs-dev/ingest-service-poc-5656c574df-j4rgn
>> 25m NormalSandboxChanged
>> pod/ingest-service-poc-5656c574df-j4rgn   Pod sandbox changed, it will be
>> killed and re-created.
>> 24m NormalPulling
>>  pod/ingest-service-poc-5656c574df-j4rgn   Pulling image
>> "image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256
>> 

Re: Not able to see redistribution of workload after node failures

[Just Marvin]

Hi,

My problem has gotten a little worse.I cordoned off a node,
rebooted it, and when the node came back up, I see that the pods have been
restarted on the newly rebooted node. This seems like a bug. Any thoughts?

Regards,
Marvin

On Fri, May 29, 2020 at 6:49 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> I'm working on a demonstration of OpenShift where we are trying to
> showcase its automatic response to various failure events - a big part of
> the demo being how it responds to node failure. I've got three worker
> nodes, and a reboot of one happens in < 2 mins. I would expect to see the
> pods on the failed / rebooted nodes migrate to the the other two nodes.
> Instead, what I see is that even when the machine is down, it takes a while
> for OpenShift to detect the failure, and at that point, I see this:
>
> zaphod@oc3027208274 constants]$ oc get pods -l app=ingest-service-poc
> NAME  READY   STATUSRESTARTS   AGE
> ingest-service-poc-5656c574df-bbq2v   1/1 Running   0  45h
> ingest-service-poc-5656c574df-d4t9l   1/1 Running   0  6d15h
> ingest-service-poc-5656c574df-gmlm7   1/1 Running   0  44h
> ingest-service-poc-5656c574df-j4rgn   0/1 Error 5  18h
> ingest-service-poc-5656c574df-kl8vp   1/1 Running   0  45h
> ingest-service-poc-5656c574df-mcvtb   1/1 Running   6  45h
> ingest-service-poc-5656c574df-rt24l   1/1 Running   0  45h
> ingest-service-poc-5656c574df-w99v6   0/1 Error 5  45h
> ingest-service-poc-5656c574df-ztl6h   1/1 Running   0  44h
>
> It looks like the pods are simply being restarted on the same node
> whenever it comes back from the reboot. The pod does not have a liveness or
> a readiness probe configured, so this is all driven by events that
> kubernetes detects from the node failure. Eventually, the pods are all
> restarted and everything is back to the "Running" state.
>
> Is this the right behavior for the cluster? Are there timeouts /
> frequency of checks for node failure etc that we can tune to show a
> redistribution of the pods when a node fails?
>
> To add to my problems, on some instances, after the node failure, this
> is the stable state:
>
> NAME  READY   STATUS RESTARTS
>   AGE
> ingest-service-poc-5656c574df-bbq2v   1/1 Running0
>  45h
> ingest-service-poc-5656c574df-d4t9l   1/1 Running0
>  6d15h
> ingest-service-poc-5656c574df-gmlm7   1/1 Running0
>  45h
> ingest-service-poc-5656c574df-j4rgn   0/1 CrashLoopBackOff   13
>   18h
> ingest-service-poc-5656c574df-kl8vp   1/1 Running0
>  45h
> ingest-service-poc-5656c574df-mcvtb   0/1 CrashLoopBackOff   13
>   45h
> ingest-service-poc-5656c574df-rt24l   1/1 Running0
>  45h
> ingest-service-poc-5656c574df-w99v6   0/1 CrashLoopBackOff   11
>   45h
> ingest-service-poc-5656c574df-ztl6h   1/1 Running0
>  45h
>
> Not sure why this happens, and how we can avoid getting here. Some
> data to go with this:
>
> [zaphod@oc3027208274 constants]$ oc get events | grep
> ingest-service-poc-5656c574df-j4rgn
> 12m NormalTaintManagerEviction
> pod/ingest-service-poc-5656c574df-j4rgn   Cancelling deletion of Pod
> irs-dev/ingest-service-poc-5656c574df-j4rgn
> 25m NormalSandboxChanged
> pod/ingest-service-poc-5656c574df-j4rgn   Pod sandbox changed, it will be
> killed and re-created.
> 24m NormalPulling
>  pod/ingest-service-poc-5656c574df-j4rgn   Pulling image
> "image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256
> :616ffb682e356002d89b8f850d43bb8cdf7db3f11e8e1c1141a03e30a05b7b0d"
> 24m NormalPulled
> pod/ingest-service-poc-5656c574df-j4rgn   Successfully pulled image
> "image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256
> :616ffb682e356002d89b8f850d43bb8cdf7db3f11e8e1c1141a03e30a05b7b0d"
> 24m NormalCreated
>  pod/ingest-service-poc-5656c574df-j4rgn   Created container
> ingest-service-poc
> 24m NormalStarted
>  pod/ingest-service-poc-5656c574df-j4rgn   Started container
> ingest-service-poc
> 24m Warning   BackOff
>  pod/ingest-service-poc-5656c574df-j4rgn   Back-off restarting failed
> container
> 11m NormalSandboxChanged
> pod/ingest-service-poc-5656c574df-j4rgn   Pod sandbox changed, it will be
> killed and re-created.
> 11m Warning   FailedCreatePodSandBox
> pod/ingest-service-poc-5656c574df-j4rgn   Failed create pod 

Not able to see redistribution of workload after node failures

[Just Marvin]

Hi,

I'm working on a demonstration of OpenShift where we are trying to
showcase its automatic response to various failure events - a big part of
the demo being how it responds to node failure. I've got three worker
nodes, and a reboot of one happens in < 2 mins. I would expect to see the
pods on the failed / rebooted nodes migrate to the the other two nodes.
Instead, what I see is that even when the machine is down, it takes a while
for OpenShift to detect the failure, and at that point, I see this:

zaphod@oc3027208274 constants]$ oc get pods -l app=ingest-service-poc
NAME  READY   STATUSRESTARTS   AGE
ingest-service-poc-5656c574df-bbq2v   1/1 Running   0  45h
ingest-service-poc-5656c574df-d4t9l   1/1 Running   0  6d15h
ingest-service-poc-5656c574df-gmlm7   1/1 Running   0  44h
ingest-service-poc-5656c574df-j4rgn   0/1 Error 5  18h
ingest-service-poc-5656c574df-kl8vp   1/1 Running   0  45h
ingest-service-poc-5656c574df-mcvtb   1/1 Running   6  45h
ingest-service-poc-5656c574df-rt24l   1/1 Running   0  45h
ingest-service-poc-5656c574df-w99v6   0/1 Error 5  45h
ingest-service-poc-5656c574df-ztl6h   1/1 Running   0  44h

It looks like the pods are simply being restarted on the same node
whenever it comes back from the reboot. The pod does not have a liveness or
a readiness probe configured, so this is all driven by events that
kubernetes detects from the node failure. Eventually, the pods are all
restarted and everything is back to the "Running" state.

Is this the right behavior for the cluster? Are there timeouts /
frequency of checks for node failure etc that we can tune to show a
redistribution of the pods when a node fails?

To add to my problems, on some instances, after the node failure, this
is the stable state:

NAME  READY   STATUS RESTARTS
AGE
ingest-service-poc-5656c574df-bbq2v   1/1 Running0
 45h
ingest-service-poc-5656c574df-d4t9l   1/1 Running0
 6d15h
ingest-service-poc-5656c574df-gmlm7   1/1 Running0
 45h
ingest-service-poc-5656c574df-j4rgn   0/1 CrashLoopBackOff   13
18h
ingest-service-poc-5656c574df-kl8vp   1/1 Running0
 45h
ingest-service-poc-5656c574df-mcvtb   0/1 CrashLoopBackOff   13
45h
ingest-service-poc-5656c574df-rt24l   1/1 Running0
 45h
ingest-service-poc-5656c574df-w99v6   0/1 CrashLoopBackOff   11
45h
ingest-service-poc-5656c574df-ztl6h   1/1 Running0
 45h

Not sure why this happens, and how we can avoid getting here. Some data
to go with this:

[zaphod@oc3027208274 constants]$ oc get events | grep
ingest-service-poc-5656c574df-j4rgn
12m NormalTaintManagerEviction
pod/ingest-service-poc-5656c574df-j4rgn   Cancelling deletion of Pod
irs-dev/ingest-service-poc-5656c574df-j4rgn
25m NormalSandboxChanged
pod/ingest-service-poc-5656c574df-j4rgn   Pod sandbox changed, it will be
killed and re-created.
24m NormalPulling
 pod/ingest-service-poc-5656c574df-j4rgn   Pulling image
"image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256
:616ffb682e356002d89b8f850d43bb8cdf7db3f11e8e1c1141a03e30a05b7b0d"
24m NormalPulled
pod/ingest-service-poc-5656c574df-j4rgn   Successfully pulled image
"image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256
:616ffb682e356002d89b8f850d43bb8cdf7db3f11e8e1c1141a03e30a05b7b0d"
24m NormalCreated
 pod/ingest-service-poc-5656c574df-j4rgn   Created container
ingest-service-poc
24m NormalStarted
 pod/ingest-service-poc-5656c574df-j4rgn   Started container
ingest-service-poc
24m Warning   BackOff
 pod/ingest-service-poc-5656c574df-j4rgn   Back-off restarting failed
container
11m NormalSandboxChanged
pod/ingest-service-poc-5656c574df-j4rgn   Pod sandbox changed, it will be
killed and re-created.
11m Warning   FailedCreatePodSandBox
pod/ingest-service-poc-5656c574df-j4rgn   Failed create pod sandbox: rpc
error: code = Unknown desc = failed to create pod network sandbox
k8s_ingest-service-poc-5656c574df-j4rgn_irs-dev_28e2831a-a5c6-4ada-9502-71bf88b06a96_5(956d00ab6ccfcbc7397498f3145f5df5872bce3edaed6f813d992152984d5516):
Multus: [irs-dev/ingest-service-poc-5656c574df-j4rgn]: error adding
container to network "k8s-pod-network": delegateAdd: error invoking
conflistAdd - "k8s-pod-network": conflistAdd: error in getting result from
AddNetworkList: error adding host side routes for interface:
calic2f571d975e, error: route (Ifindex: 41, Dst: 172.30.75.22/32, Scope:
253) already exists for an interface other than 'calic2f571d975e'
6m52s   NormalPulling
 pod/ingest-service-poc-5656c574df-j4rgn   Pulling image
"image-registry.openshift-image-registry.svc:5000/irs-dev/ingest-service-poc@sha256

rebalancing workloads

[Just Marvin]

Hi,

If I add new nodes to an openshift v4 cluster, is there a command that
will trigger a workload rebalance to take advantage of the new node? Or
will I have to do something like delete existing pods so that the scheduler
recreates it and upon recreate, it puts it on the new nodes?

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

Re: wait for build triggered by new-app

[Just Marvin]

Ben,

That explains it the build wait failure - you can see from the output I
included at the end of my email, that I'm at v4.3.12 . Does this explain my
observations with the project delete not waiting correctly either?

Regards,
Marvin


On Thu, May 7, 2020 at 2:53 PM Ben Parees  wrote:

> what version is your cluster?  conditions were only recently added to the
> build.status section to OCP 4.4. oc wait doesn't work no resources that
> don't have a status.conditions section.
>
>
>
>
> On Thu, May 7, 2020 at 2:47 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Ben,
>>
>>  It looks like I have a general problem with "oc wait" or waits, in
>> general, not working reliably on my cluster. Here is my code now:
>>
>> #  Step 7: Wait for the build to start. For some reason, the wait command
>> doesn't work, saying that the build doesn't exist even
>> #  though the new-app command has completed.
>> buildName=""
>> while true; do
>> sleep 1
>> buildName=`oc get build | sed '1d' | awk '/^teams[-]/{print $1;
>> exit 0}!/^teams[-]/{exit 1}'`
>> if [[ $? -eq 0 ]]; then
>> echo "build detected. Waiting for it to complete..."
>> break;
>> fi
>> done
>> #  Step 8: wait for the build to complete. Sigh. Doesn't work.
>> oc wait build/${buildName} --for=condition=Complete --timeout=240s
>>
>> ..which produces this output:
>>
>> --> Success
>> Build scheduled, use 'oc logs -f bc/teams' to track its progress.
>> Application is not exposed. You can expose services to the outside
>> world by executing one or more of the commands below:
>>  'oc expose svc/teams'
>> Run 'oc status' to view your app.
>> build detected. Waiting for it to complete...
>> error: timed out waiting for the condition on builds/teams-1
>>
>> .which may seem ok, but is a problem because the build completes in
>> less than 4 mins, so the timeout should never happen. Here is a portion of
>> the build/teams-1 yaml:
>>
>>   phase: Complete
>>   stages:
>>   - durationMilliseconds: 341
>> name: FetchInputs
>> startTime: "2020-05-07T18:35:37Z"
>> steps:
>> - durationMilliseconds: 341
>>   name: FetchGitSource
>>   startTime: "2020-05-07T18:35:37Z"
>>   - durationMilliseconds: 39822
>> name: PullImages
>> startTime: "2020-05-07T18:35:40Z"
>> steps:
>> - durationMilliseconds: 21704
>>   name: PullBaseImage
>>   startTime: "2020-05-07T18:35:40Z"
>> - durationMilliseconds: 18117
>>   name: PullBaseImage
>>   startTime: "2020-05-07T18:36:02Z"
>>   - durationMilliseconds: 55408
>> name: Build
>> startTime: "2020-05-07T18:36:20Z"
>> steps:
>> - durationMilliseconds: 55408
>>   name: DockerBuild
>>   startTime: "2020-05-07T18:36:20Z"
>>   - durationMilliseconds: 2102
>> name: PushImage
>> startTime: "2020-05-07T18:37:15Z"
>> steps:
>> - durationMilliseconds: 2102
>>   name: PushDockerImage
>>   startTime: "2020-05-07T18:37:15Z"
>>   startTimestamp: "2020-05-07T18:35:35Z"
>>
>> .so the build actually completes in about 2 mins.
>>
>> Other observations:
>>
>> [zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
>> --wait=true;date
>> project.project.openshift.io "demo-mongo-apps" deleted
>> Thu May  7 14:11:46 EDT 2020
>> [zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
>> --wait=true;date
>> project.project.openshift.io "demo-mongo-apps" deleted
>> Thu May  7 14:11:48 EDT 2020
>> [zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
>> --wait=true;date
>> project.project.openshift.io "demo-mongo-apps" deleted
>> Thu May  7 14:11:50 EDT 2020
>> [zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
>> --wait=true;date
>> project.project.openshift.io "demo-mongo-apps" deleted
>> Thu May  7 14:11:51 EDT 2020
>> .and it takes about 30 seconds or so for the delete to take effect.
>>
>> One unusual think I've noticed about my cluster (I didn't set it up)
>> is that it is a three node cluster with all three nodes sharing the master
>> and worker node roles. Could this be a cause of the symptoms I'm seeing?
>>
>> [

Re: wait for build triggered by new-app

[Just Marvin]

Ben,

 It looks like I have a general problem with "oc wait" or waits, in
general, not working reliably on my cluster. Here is my code now:

#  Step 7: Wait for the build to start. For some reason, the wait command
doesn't work, saying that the build doesn't exist even
#  though the new-app command has completed.
buildName=""
while true; do
sleep 1
buildName=`oc get build | sed '1d' | awk '/^teams[-]/{print $1;
exit 0}!/^teams[-]/{exit 1}'`
if [[ $? -eq 0 ]]; then
echo "build detected. Waiting for it to complete..."
break;
fi
done
#  Step 8: wait for the build to complete. Sigh. Doesn't work.
oc wait build/${buildName} --for=condition=Complete --timeout=240s

..which produces this output:

--> Success
Build scheduled, use 'oc logs -f bc/teams' to track its progress.
Application is not exposed. You can expose services to the outside
world by executing one or more of the commands below:
 'oc expose svc/teams'
Run 'oc status' to view your app.
build detected. Waiting for it to complete...
error: timed out waiting for the condition on builds/teams-1

.which may seem ok, but is a problem because the build completes in
less than 4 mins, so the timeout should never happen. Here is a portion of
the build/teams-1 yaml:

  phase: Complete
  stages:
  - durationMilliseconds: 341
name: FetchInputs
startTime: "2020-05-07T18:35:37Z"
steps:
- durationMilliseconds: 341
  name: FetchGitSource
  startTime: "2020-05-07T18:35:37Z"
  - durationMilliseconds: 39822
name: PullImages
startTime: "2020-05-07T18:35:40Z"
steps:
- durationMilliseconds: 21704
  name: PullBaseImage
  startTime: "2020-05-07T18:35:40Z"
- durationMilliseconds: 18117
  name: PullBaseImage
  startTime: "2020-05-07T18:36:02Z"
  - durationMilliseconds: 55408
name: Build
startTime: "2020-05-07T18:36:20Z"
steps:
- durationMilliseconds: 55408
  name: DockerBuild
  startTime: "2020-05-07T18:36:20Z"
  - durationMilliseconds: 2102
name: PushImage
startTime: "2020-05-07T18:37:15Z"
steps:
- durationMilliseconds: 2102
  name: PushDockerImage
  startTime: "2020-05-07T18:37:15Z"
  startTimestamp: "2020-05-07T18:35:35Z"

.so the build actually completes in about 2 mins.

Other observations:

[zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
--wait=true;date
project.project.openshift.io "demo-mongo-apps" deleted
Thu May  7 14:11:46 EDT 2020
[zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
--wait=true;date
project.project.openshift.io "demo-mongo-apps" deleted
Thu May  7 14:11:48 EDT 2020
[zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
--wait=true;date
project.project.openshift.io "demo-mongo-apps" deleted
Thu May  7 14:11:50 EDT 2020
[zaphod@oc3027208274 gatt]$ oc delete project demo-mongo-apps
--wait=true;date
project.project.openshift.io "demo-mongo-apps" deleted
Thu May  7 14:11:51 EDT 2020
.and it takes about 30 seconds or so for the delete to take effect.

One unusual think I've noticed about my cluster (I didn't set it up) is
that it is a three node cluster with all three nodes sharing the master and
worker node roles. Could this be a cause of the symptoms I'm seeing?

[zaphod@oc3027208274 gatt]$ oc version
Client Version: openshift-clients-4.3.0-201909231341
Server Version: 4.3.12
Kubernetes Version: v1.16.2
[zaphod@oc3027208274 gatt]$

Regards,
Marvin







On Wed, May 6, 2020 at 1:20 PM Ben Parees  wrote:

>
>
> On Wed, May 6, 2020 at 12:50 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Ben,
>>
>>I appreciate the pointer, but this doesn't seem to do the right thing.
>> Here is the relevant portion of my code:
>>
>
>> oc new-app --name=teams git@ -e MONGODB_USER=
>> -e MONGODB_PASSWORD= -e MONGODB_HOST=mongodb -e MONGODB_PORT=27017 -e
>> MONGODB_DATABASE=teamdb --source-secret=
>> #  Adding waits for teams and teams-1 because the build resource seems to
>> be teams-1
>> oc wait build/teams --for=condition=Complete
>>
>
> this line won't do anything, there's no build named "teams", only
> "teams-1" (and later teams-2, etc)
>
>
>
>> oc wait build/teams-1 --for=condition=Complete
>>
>
> this looks correct
>
>
>>And here is the output:
>>
>> warning: Cannot check if git requires authentication.
>> --> Found container image 1db9786 (6 months old) from docker.io for "
>> docker.io/websphere-liberty:javaee8"
>>
>> * An image stream tag will be created as "websphere-liberty:javaee8"
>> that w

Re: helm - revisited

[Just Marvin]

Hi,

Anyone? Is there an OpenShift specific version of helm? If so, where
would the code for that be? I spent some time searching the openshift
github repo and didn't find anything.

Regards,
Marvin

On Sat, Apr 11, 2020 at 11:21 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> Now that there is some level of official support [1] within the
> platform for Helm, I thought I'd delve into how this technology works.
> Particularly w.r.t special OpenShift-only resources like BuildConfigs and
> ImageStreams, and DeploymentConfigs. My first experiment with a
> DeploymentConfig went well, but I thought to dig a little deeper and found
> a reference to this Go file in the Helm code [2] - which seems to be the
> thing that specifies the order in which templates within a chart are
> executed. So I'm mystified as to how OpenShift resource types will work at
> all. Is there a way to ensure that OpenShift specific templates get
> executed in a specific order?
>
> Regards,
> Marvin
>
> [1]
> https://docs.openshift.com/container-platform/4.3/cli_reference/helm_cli/getting-started-with-helm-on-openshift-container-platform.html
> [2]
> https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

helm - revisited

[Just Marvin]

Hi,

Now that there is some level of official support [1] within the
platform for Helm, I thought I'd delve into how this technology works.
Particularly w.r.t special OpenShift-only resources like BuildConfigs and
ImageStreams, and DeploymentConfigs. My first experiment with a
DeploymentConfig went well, but I thought to dig a little deeper and found
a reference to this Go file in the Helm code [2] - which seems to be the
thing that specifies the order in which templates within a chart are
executed. So I'm mystified as to how OpenShift resource types will work at
all. Is there a way to ensure that OpenShift specific templates get
executed in a specific order?

Regards,
Marvin

[1]
https://docs.openshift.com/container-platform/4.3/cli_reference/helm_cli/getting-started-with-helm-on-openshift-container-platform.html
[2]
https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

logging for an openshift service

[Just Marvin]

Hi,

Is there a way I can enable logging or otherwise determine which pod
(of all the ones that its selector selects) a service is sending requests
to?

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

Re: route not load balancing

[Just Marvin]

Hi,

The key was to set the *haproxy.router.openshift.io/disable_cookies
<http://haproxy.router.openshift.io/disable_cookies>* annotation to true.

Regards,
Marvin

On Mon, Dec 16, 2019 at 9:53 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Dan,
>
> Thanks for the pointer. It didn't solve my problem. Whats worse, is
> that your link is to the 3.11 docs, and I tried the same annotation on a
> 3.11 install, and it didn't work there either. I have to demonstrate the
> load balancing to a customer, and my cheat was to use the 
> *haproxy.router.openshift.io/pod-concurrent-connections
> <http://haproxy.router.openshift.io/pod-concurrent-connections>*  annotation
> - when running "ab" with 10 concurrent connections, and
> "pods-conccurrent-connections" set to 6. I do see the spill-over traffic
> going to the second pod.
>
> But this is definitely a cheat for me. I would like to get the
> "balance" annotation, or whatever is the right approach, working. Is there
> a way to troubleshoot this and figure out what is going wrong?
>
> Regards,
> Marvin
>
> On Mon, Dec 16, 2019 at 8:22 AM Dan Mace  wrote:
>
>>
>>
>> On Mon, Dec 16, 2019 at 8:12 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> In the openshift-ingress/router-default pod, in
>>> /var/lib/haproxy/conf/haproxy.config I see:
>>>
>>> backend be_edge_http:session-persistence:song-demo
>>>   mode http
>>>   option redispatch
>>>   option forwardfor
>>>
>>> *  balance leastconn*
>>>   timeout check 5000ms
>>>   http-request set-header X-Forwarded-Host %[req.hdr(host)]
>>>   http-request set-header X-Forwarded-Port %[dst_port]
>>>   http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
>>>   http-request set-header X-Forwarded-Proto https if { ssl_fc }
>>>   http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn
>>> -i h2 }
>>>   # Forwarded header: quote IPv6 addresses and values that may be empty
>>> as per https://tools.ietf.org/html/rfc7239
>>>   http-request add-header Forwarded
>>> for=%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=\"%[req.hdr(X-Forwarded-Proto-Version)]\"
>>>   cookie 3e15d2ed54afa750c6c99f3e7974d5f8 insert indirect nocache
>>> httponly secure
>>>   server pod:song-demo-6-tw5qr:song-demo:10.128.0.46:9080
>>> 10.128.0.46:9080 cookie 88434433dbc1caefd053e8d5252218f0 weight 256
>>> check inter 5000ms
>>>   server pod:song-demo-6-nz8c2:song-demo:10.128.0.47:9080
>>> 10.128.0.47:9080 cookie c67ffb0cd9ed5115a63c2f6b0a39151c weight 256
>>> check inter 5000ms
>>> sh-4.2$
>>>
>>> I probably want "roundrobin" instead of that, though I would argue
>>> the system isn't doing what is implied by "leastconn" either. Is there a
>>> way to change that setting to what I need?
>>>
>>> Regards,
>>> Marvin
>>>
>>
>>
>> Marvin,
>>
>> You can try the "haproxy.router.openshift.io/balance" annotation on your
>> Route resource to configure the balancing strategy[1].
>>
>>
>> https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#route-specific-annotations
>>
>>
>> On Sun, Dec 15, 2019 at 8:21 PM Just Marvin <
>>> marvin.the.cynical.ro...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using code-ready containers and I've scaled my pod to do, but
>>>> when I hit it form a for loop in a shell script, I get back results
>>>> indicating that its only being routed to one of the pods. Is there some
>>>> setting that I need to tweak to make things load balanced even at low load?
>>>>
>>>> [zaphod@oc6010654212 session-song-demo]$ oc describe svc song-demo
>>>> Name:  song-demo
>>>> Namespace: session-persistence
>>>> Labels:app=song-demo
>>>>app.kubernetes.io/component=song-demo
>>>>app.kubernetes.io/instance=song-demo
>>>> Annotations:   openshift.io/generated-by: OpenShiftNewApp
>>>> Selector:  deploymentconfig=song-demo
>>>> Type:  ClusterIP
>>>> IP:172.30.140.43
>>>> Port:  9080-tcp  9080/TCP
>>>> TargetPort:9080/TCP
>>>&g

Re: route not load balancing

[Just Marvin]

Dan,

Thanks for the pointer. It didn't solve my problem. Whats worse, is
that your link is to the 3.11 docs, and I tried the same annotation on a
3.11 install, and it didn't work there either. I have to demonstrate the
load balancing to a customer, and my cheat was to use the
*haproxy.router.openshift.io/pod-concurrent-connections
<http://haproxy.router.openshift.io/pod-concurrent-connections>*  annotation
- when running "ab" with 10 concurrent connections, and
"pods-conccurrent-connections" set to 6. I do see the spill-over traffic
going to the second pod.

But this is definitely a cheat for me. I would like to get the
"balance" annotation, or whatever is the right approach, working. Is there
a way to troubleshoot this and figure out what is going wrong?

Regards,
Marvin

On Mon, Dec 16, 2019 at 8:22 AM Dan Mace  wrote:

>
>
> On Mon, Dec 16, 2019 at 8:12 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> In the openshift-ingress/router-default pod, in
>> /var/lib/haproxy/conf/haproxy.config I see:
>>
>> backend be_edge_http:session-persistence:song-demo
>>   mode http
>>   option redispatch
>>   option forwardfor
>>
>> *  balance leastconn*
>>   timeout check 5000ms
>>   http-request set-header X-Forwarded-Host %[req.hdr(host)]
>>   http-request set-header X-Forwarded-Port %[dst_port]
>>   http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
>>   http-request set-header X-Forwarded-Proto https if { ssl_fc }
>>   http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn
>> -i h2 }
>>   # Forwarded header: quote IPv6 addresses and values that may be empty
>> as per https://tools.ietf.org/html/rfc7239
>>   http-request add-header Forwarded
>> for=%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=\"%[req.hdr(X-Forwarded-Proto-Version)]\"
>>   cookie 3e15d2ed54afa750c6c99f3e7974d5f8 insert indirect nocache
>> httponly secure
>>   server pod:song-demo-6-tw5qr:song-demo:10.128.0.46:9080
>> 10.128.0.46:9080 cookie 88434433dbc1caefd053e8d5252218f0 weight 256
>> check inter 5000ms
>>   server pod:song-demo-6-nz8c2:song-demo:10.128.0.47:9080
>> 10.128.0.47:9080 cookie c67ffb0cd9ed5115a63c2f6b0a39151c weight 256
>> check inter 5000ms
>> sh-4.2$
>>
>> I probably want "roundrobin" instead of that, though I would argue
>> the system isn't doing what is implied by "leastconn" either. Is there a
>> way to change that setting to what I need?
>>
>> Regards,
>> Marvin
>>
>
>
> Marvin,
>
> You can try the "haproxy.router.openshift.io/balance" annotation on your
> Route resource to configure the balancing strategy[1].
>
>
> https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#route-specific-annotations
>
>
> On Sun, Dec 15, 2019 at 8:21 PM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm using code-ready containers and I've scaled my pod to do, but
>>> when I hit it form a for loop in a shell script, I get back results
>>> indicating that its only being routed to one of the pods. Is there some
>>> setting that I need to tweak to make things load balanced even at low load?
>>>
>>> [zaphod@oc6010654212 session-song-demo]$ oc describe svc song-demo
>>> Name:  song-demo
>>> Namespace: session-persistence
>>> Labels:app=song-demo
>>>app.kubernetes.io/component=song-demo
>>>app.kubernetes.io/instance=song-demo
>>> Annotations:   openshift.io/generated-by: OpenShiftNewApp
>>> Selector:  deploymentconfig=song-demo
>>> Type:  ClusterIP
>>> IP:172.30.140.43
>>> Port:  9080-tcp  9080/TCP
>>> TargetPort:9080/TCP
>>> Endpoints: 10.128.0.42:9080,10.128.0.43:9080
>>> Port:  9443-tcp  9443/TCP
>>> TargetPort:9443/TCP
>>> Endpoints: 10.128.0.42:9443,10.128.0.43:9443
>>> Session Affinity:  None
>>> Events:
>>> [zaphod@oc6010654212 session-song-demo]$ oc describe route song-demo
>>> Name: song-demo
>>> Namespace: session-persistence
>>> Created: 5 hours ago
>>> Labels: app=song-demo
>>> app.kubernetes.io/component=song-demo
>>> app.kubernetes.io/instance=song-demo
>>> Annotations: 
>

Re: route not load balancing

[Just Marvin]

Hi,

In the openshift-ingress/router-default pod, in
/var/lib/haproxy/conf/haproxy.config I see:

backend be_edge_http:session-persistence:song-demo
  mode http
  option redispatch
  option forwardfor

*  balance leastconn*
  timeout check 5000ms
  http-request set-header X-Forwarded-Host %[req.hdr(host)]
  http-request set-header X-Forwarded-Port %[dst_port]
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn -i
h2 }
  # Forwarded header: quote IPv6 addresses and values that may be empty as
per https://tools.ietf.org/html/rfc7239
  http-request add-header Forwarded
for=%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=\"%[req.hdr(X-Forwarded-Proto-Version)]\"
  cookie 3e15d2ed54afa750c6c99f3e7974d5f8 insert indirect nocache httponly
secure
  server pod:song-demo-6-tw5qr:song-demo:10.128.0.46:9080 10.128.0.46:9080
cookie 88434433dbc1caefd053e8d5252218f0 weight 256 check inter 5000ms
  server pod:song-demo-6-nz8c2:song-demo:10.128.0.47:9080 10.128.0.47:9080
cookie c67ffb0cd9ed5115a63c2f6b0a39151c weight 256 check inter 5000ms
sh-4.2$

I probably want "roundrobin" instead of that, though I would argue the
system isn't doing what is implied by "leastconn" either. Is there a way to
change that setting to what I need?

Regards,
Marvin

On Sun, Dec 15, 2019 at 8:21 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> I'm using code-ready containers and I've scaled my pod to do, but when
> I hit it form a for loop in a shell script, I get back results indicating
> that its only being routed to one of the pods. Is there some setting that I
> need to tweak to make things load balanced even at low load?
>
> [zaphod@oc6010654212 session-song-demo]$ oc describe svc song-demo
> Name:  song-demo
> Namespace: session-persistence
> Labels:app=song-demo
>app.kubernetes.io/component=song-demo
>app.kubernetes.io/instance=song-demo
> Annotations:   openshift.io/generated-by: OpenShiftNewApp
> Selector:  deploymentconfig=song-demo
> Type:  ClusterIP
> IP:172.30.140.43
> Port:  9080-tcp  9080/TCP
> TargetPort:9080/TCP
> Endpoints: 10.128.0.42:9080,10.128.0.43:9080
> Port:  9443-tcp  9443/TCP
> TargetPort:9443/TCP
> Endpoints: 10.128.0.42:9443,10.128.0.43:9443
> Session Affinity:  None
> Events:
> [zaphod@oc6010654212 session-song-demo]$ oc describe route song-demo
> Name: song-demo
> Namespace: session-persistence
> Created: 5 hours ago
> Labels: app=song-demo
> app.kubernetes.io/component=song-demo
> app.kubernetes.io/instance=song-demo
> Annotations: 
> Requested Host: song-demo.apps-crc.testing
>  exposed on router default (host apps-crc.testing) 5 hours ago
> Path: 
> TLS Termination: edge
> Insecure Policy: 
> Endpoint Port: 9080-tcp
>
> Service: song-demo
> Weight: 100 (100%)
> Endpoints: 10.128.0.42:9443, 10.128.0.43:9443, 10.128.0.42:9080 + 1
> more...
> [zaphod@oc6010654212 session-song-demo]$
>
> Regards,
> Marvin
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

route not load balancing

[Just Marvin]

Hi,

I'm using code-ready containers and I've scaled my pod to do, but when
I hit it form a for loop in a shell script, I get back results indicating
that its only being routed to one of the pods. Is there some setting that I
need to tweak to make things load balanced even at low load?

[zaphod@oc6010654212 session-song-demo]$ oc describe svc song-demo
Name:  song-demo
Namespace: session-persistence
Labels:app=song-demo
   app.kubernetes.io/component=song-demo
   app.kubernetes.io/instance=song-demo
Annotations:   openshift.io/generated-by: OpenShiftNewApp
Selector:  deploymentconfig=song-demo
Type:  ClusterIP
IP:172.30.140.43
Port:  9080-tcp  9080/TCP
TargetPort:9080/TCP
Endpoints: 10.128.0.42:9080,10.128.0.43:9080
Port:  9443-tcp  9443/TCP
TargetPort:9443/TCP
Endpoints: 10.128.0.42:9443,10.128.0.43:9443
Session Affinity:  None
Events:
[zaphod@oc6010654212 session-song-demo]$ oc describe route song-demo
Name: song-demo
Namespace: session-persistence
Created: 5 hours ago
Labels: app=song-demo
app.kubernetes.io/component=song-demo
app.kubernetes.io/instance=song-demo
Annotations: 
Requested Host: song-demo.apps-crc.testing
 exposed on router default (host apps-crc.testing) 5 hours ago
Path: 
TLS Termination: edge
Insecure Policy: 
Endpoint Port: 9080-tcp

Service: song-demo
Weight: 100 (100%)
Endpoints: 10.128.0.42:9443, 10.128.0.43:9443, 10.128.0.42:9080 + 1 more...
[zaphod@oc6010654212 session-song-demo]$

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

[solved] Re: route still not working....

[Just Marvin]

Hi,

Sigh. My. Fault. Entirely. In the websphere configuration file, here is
the relevant bit:




The comment is provided by the product. The "host" attribute is not
present by default. All I had to do was to add that attribute, and things
started working.

Regards,
Marvin


On Sun, Dec 15, 2019 at 3:30 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Jean-Francois,
>
> Hmmthat's not what I'm seeing. I do get logs that indicate that
> the liberty server is starting up correctly with the app. In fact, using
> port-forwarding shows that my app is running correctly in the liberty
> runtime. The mystifying piece for me is why the router and the liberty pod
> are not interacting correctly.
>
> Nevertheless, I will investigate along your suggestion. Thanks!
>
> Regards,
> Marvin
>
> On Sun, Dec 15, 2019 at 2:59 PM Jean-Francois Maury 
> wrote:
>
>> What I mean is that if you create your application with
>>
>> oc new-app --name=simple https://github.com/kstephen314159/simple-stuff.git
>>
>>
>> then the based docker image used will be te default for Java and thus you
>> pod will not start as it will miss the Liberty runtime.
>> Check you pod logs
>>
>> On Sun, Dec 15, 2019 at 8:51 PM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Jean-Francois / Jeff,
>>>
>>> I thought I was doing exactly that in my Dockerfile. See here:
>>> https://github.com/kstephen314159/simple-stuff/blob/master/Dockerfile .
>>> If that is not what you meant, please clarify.
>>>
>>> Regards,
>>> Marvin
>>>
>>> On Sun, Dec 15, 2019 at 2:36 PM Jean-Francois Maury 
>>> wrote:
>>>
>>>> You need to specific the Docker image when you create your app from the
>>>> repo
>>>>
>>>>
>>>>
>>>> On Sun, Dec 15, 2019 at 8:19 PM Just Marvin <
>>>> marvin.the.cynical.ro...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Starting a new thread to clear my head. Its only been 8 hours
>>>>> since I started banging my head on the desk because of this problem, but 
>>>>> it
>>>>> feels like 80. A little more background than in my previous thread:
>>>>>
>>>>>
>>>>>- The container I'm working with is websphere-liberty. I can
>>>>>simply do a "...new-app --docker-image=
>>>>>docker.io/websphere-liberty:javaee8", and that container will spin
>>>>>up, and the route will respond correctly when pointed to the service.
>>>>>- With an application payload, I have been unable to get this
>>>>>working. I can use port-forwarding and verify that *my service is
>>>>>functioning properly on OpenShift,* but the route refuses to talk
>>>>>to it.
>>>>>- I have tried regular routes, and edge terminated routes.
>>>>>Somewhere around hour 4 is when I gave up on the more complex 
>>>>> reencrypt and
>>>>>passthrough options.
>>>>>- My git repo for my very simple app:
>>>>>https://github.com/kstephen314159/simple-stuff
>>>>>
>>>>> I have enabled the transport level tracing on liberty, but it
>>>>> doesn't show any activity when I submit the request to the route. So, at
>>>>> this point, I'm mystified, because the route doesn't seem to like the
>>>>> service, but I don't know why. Would appreciate any pointers in either
>>>>> proving or disproving that the route is working correctly.
>>>>>
>>>>> Regards,
>>>>> Marvin
>>>>> ___
>>>>> users mailing list
>>>>> users@lists.openshift.redhat.com
>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Jeff Maury
>>>>
>>>> Manager, DevTools
>>>>
>>>> Red Hat EMEA <https://www.redhat.com>
>>>>
>>>> jma...@redhat.com
>>>> @RedHat <https://twitter.com/redhat>   Red Hat
>>>> <https://www.linkedin.com/company/red-hat>  Red Hat
>>>> <https://www.facebook.com/RedHatInc>
>>>> <https://www.redhat.com>
>>>> <https://redhat.com/summit>
>>>>
>>>
>>
>> --
>>
>> Jeff Maury
>>
>> Manager, DevTools
>>
>> Red Hat EMEA <https://www.redhat.com>
>>
>> jma...@redhat.com
>> @RedHat <https://twitter.com/redhat>   Red Hat
>> <https://www.linkedin.com/company/red-hat>  Red Hat
>> <https://www.facebook.com/RedHatInc>
>> <https://www.redhat.com>
>> <https://redhat.com/summit>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: route still not working....

[Just Marvin]

Jean-Francois,

Hmmthat's not what I'm seeing. I do get logs that indicate that the
liberty server is starting up correctly with the app. In fact, using
port-forwarding shows that my app is running correctly in the liberty
runtime. The mystifying piece for me is why the router and the liberty pod
are not interacting correctly.

Nevertheless, I will investigate along your suggestion. Thanks!

Regards,
Marvin

On Sun, Dec 15, 2019 at 2:59 PM Jean-Francois Maury 
wrote:

> What I mean is that if you create your application with
>
> oc new-app --name=simple https://github.com/kstephen314159/simple-stuff.git
>
>
> then the based docker image used will be te default for Java and thus you
> pod will not start as it will miss the Liberty runtime.
> Check you pod logs
>
> On Sun, Dec 15, 2019 at 8:51 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Jean-Francois / Jeff,
>>
>> I thought I was doing exactly that in my Dockerfile. See here:
>> https://github.com/kstephen314159/simple-stuff/blob/master/Dockerfile .
>> If that is not what you meant, please clarify.
>>
>> Regards,
>> Marvin
>>
>> On Sun, Dec 15, 2019 at 2:36 PM Jean-Francois Maury 
>> wrote:
>>
>>> You need to specific the Docker image when you create your app from the
>>> repo
>>>
>>>
>>>
>>> On Sun, Dec 15, 2019 at 8:19 PM Just Marvin <
>>> marvin.the.cynical.ro...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Starting a new thread to clear my head. Its only been 8 hours since
>>>> I started banging my head on the desk because of this problem, but it feels
>>>> like 80. A little more background than in my previous thread:
>>>>
>>>>
>>>>- The container I'm working with is websphere-liberty. I can simply
>>>>do a "...new-app --docker-image=docker.io/websphere-liberty:javaee8",
>>>>and that container will spin up, and the route will respond correctly 
>>>> when
>>>>pointed to the service.
>>>>- With an application payload, I have been unable to get this
>>>>working. I can use port-forwarding and verify that *my service is
>>>>functioning properly on OpenShift,* but the route refuses to talk
>>>>to it.
>>>>- I have tried regular routes, and edge terminated routes.
>>>>Somewhere around hour 4 is when I gave up on the more complex reencrypt 
>>>> and
>>>>passthrough options.
>>>>- My git repo for my very simple app:
>>>>https://github.com/kstephen314159/simple-stuff
>>>>
>>>> I have enabled the transport level tracing on liberty, but it
>>>> doesn't show any activity when I submit the request to the route. So, at
>>>> this point, I'm mystified, because the route doesn't seem to like the
>>>> service, but I don't know why. Would appreciate any pointers in either
>>>> proving or disproving that the route is working correctly.
>>>>
>>>> Regards,
>>>> Marvin
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>
>>>
>>> --
>>>
>>> Jeff Maury
>>>
>>> Manager, DevTools
>>>
>>> Red Hat EMEA <https://www.redhat.com>
>>>
>>> jma...@redhat.com
>>> @RedHat <https://twitter.com/redhat>   Red Hat
>>> <https://www.linkedin.com/company/red-hat>  Red Hat
>>> <https://www.facebook.com/RedHatInc>
>>> <https://www.redhat.com>
>>> <https://redhat.com/summit>
>>>
>>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA <https://www.redhat.com>
>
> jma...@redhat.com
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>
> <https://redhat.com/summit>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: route still not working....

[Just Marvin]

Jean-Francois / Jeff,

I thought I was doing exactly that in my Dockerfile. See here:
https://github.com/kstephen314159/simple-stuff/blob/master/Dockerfile . If
that is not what you meant, please clarify.

Regards,
Marvin

On Sun, Dec 15, 2019 at 2:36 PM Jean-Francois Maury 
wrote:

> You need to specific the Docker image when you create your app from the
> repo
>
>
>
> On Sun, Dec 15, 2019 at 8:19 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> Starting a new thread to clear my head. Its only been 8 hours since I
>> started banging my head on the desk because of this problem, but it feels
>> like 80. A little more background than in my previous thread:
>>
>>
>>- The container I'm working with is websphere-liberty. I can simply
>>do a "...new-app --docker-image=docker.io/websphere-liberty:javaee8",
>>and that container will spin up, and the route will respond correctly when
>>pointed to the service.
>>- With an application payload, I have been unable to get this
>>working. I can use port-forwarding and verify that *my service is
>>functioning properly on OpenShift,* but the route refuses to talk to
>>it.
>>- I have tried regular routes, and edge terminated routes. Somewhere
>>around hour 4 is when I gave up on the more complex reencrypt and
>>passthrough options.
>>- My git repo for my very simple app:
>>https://github.com/kstephen314159/simple-stuff
>>
>> I have enabled the transport level tracing on liberty, but it doesn't
>> show any activity when I submit the request to the route. So, at this
>> point, I'm mystified, because the route doesn't seem to like the service,
>> but I don't know why. Would appreciate any pointers in either proving or
>> disproving that the route is working correctly.
>>
>> Regards,
>> Marvin
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA <https://www.redhat.com>
>
> jma...@redhat.com
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>
> <https://redhat.com/summit>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

route still not working....

[Just Marvin]

Hi,

Starting a new thread to clear my head. Its only been 8 hours since I
started banging my head on the desk because of this problem, but it feels
like 80. A little more background than in my previous thread:


   - The container I'm working with is websphere-liberty. I can simply do a
   "...new-app --docker-image=docker.io/websphere-liberty:javaee8", and
   that container will spin up, and the route will respond correctly when
   pointed to the service.
   - With an application payload, I have been unable to get this working. I
   can use port-forwarding and verify that *my service is functioning
   properly on OpenShift,* but the route refuses to talk to it.
   - I have tried regular routes, and edge terminated routes. Somewhere
   around hour 4 is when I gave up on the more complex reencrypt and
   passthrough options.
   - My git repo for my very simple app:
   https://github.com/kstephen314159/simple-stuff

I have enabled the transport level tracing on liberty, but it doesn't
show any activity when I submit the request to the route. So, at this
point, I'm mystified, because the route doesn't seem to like the service,
but I don't know why. Would appreciate any pointers in either proving or
disproving that the route is working correctly.

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

route not working and I'm at my wits end

[Just Marvin]

Hi,

I'm able to use port-forwarding to verify that my service is
functioning properly.

curl -v -u abcd:abcd@ -H "Accept: application/json" --cookie-jar cookie-jar
--cookie cookie-jar
http://localhost:9080/session-song-demo/sing/song?seen=47
* About to connect() to localhost port 9080 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 9080 (#0)
* Server auth using Basic with user 'abcd'
> GET /session-song-demo/sing/song?seen=47 HTTP/1.1
> Authorization: Basic YWJjZDphYmNkQA==
> User-Agent: curl/7.29.0
> Host: localhost:9080
> Cookie:
JSESSIONID=0001cbGiUXt_VtxdTW9Xa8c1W_s:c5f5e43e-3adb-4a42-bf12-e67265711b02;
LtpaToken2=IL+wSFBcnsOi9+fpHR8PgzJak7eRwRAPoSdHPRZoSjJuSMA11/DKqYA8Lld79i5LB6j51ihR5OqXKifGQAxC3t70aQxRWH2y2xqS7L+lairHAAu86QARt2OzYDX39FA/N8IPwcCJOwlm0Z89ZClks7PEQmy0csAV+CTo4uHIiZu9CY1kOfp2oH9Q9H3KkTZQGLHNKmwBF41BXmWtSwc6AvNbbDL6kuFjAi+Ahui8QjBAPKAIMb7Z4PKMdhwkzMKUObgS6iBAy7tHeQMknrmolzRpmz00mpfjVQvkzKNzvL9VZ74a27MC0vRM5N185nCr
> Accept: application/json
>
< HTTP/1.1 200 OK
< X-Powered-By: Servlet/4.0
< Content-Type: application/json
< Date: Fri, 13 Dec 2019 07:39:35 GMT
< Content-Language: en-US
< Content-Length: 33
<
* Connection #0 to host localhost left intact
{"count":43,"name":"nightingale"}

However, when trying to get at this service through a route, it gives
me the catch-all router error page:
[image: image.png]
Here is the route definition:

zaphod@oc6010654212 session-song-demo]$ oc describe route song-demo
Name: song-demo
Namespace: session-persistence
Created: 43 hours ago
Labels: app=song-demo
app.kubernetes.io/component=song-demo
app.kubernetes.io/instance=song-demo
Annotations: 
Requested Host: song-demo.apps-crc.testing
 exposed on router default (host apps-crc.testing) 43 hours ago
Path: 
TLS Termination: 
Insecure Policy: 
Endpoint Port: 9080-tcp

Service: song-demo
Weight: 100 (100%)
Endpoints: 10.128.1.211:9443, 10.128.1.211:9080
[zaphod@oc6010654212 session-song-demo]$

I've been through numerous variations without much success, and the
logs of the router in openshift-ingress aren't showing anything
significant. Is there a way to troubleshoot this and find out whats going
wrong?

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

where does CRC store its data?

[Just Marvin]

Hi,

On my host system, I see:

[zaphod@oc6010654212 code]$ oc get pv
NAME CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS  CLAIM
  STORAGECLASS   REASON   AGE
pv0001   100Gi  RWO,ROX,RWXRecycle  Bound
openshift-image-registry/crc-image-registry-storage
  22d
pv0002   100Gi  RWO,ROX,RWXRecycle  Available
  22d
pv0003   100Gi  RWO,ROX,RWXRecycle  Available
  22d
pv0004   100Gi  RWO,ROX,RWXRecycle  Available
  22d
.
.
.
pv0030   100Gi  RWO,ROX,RWXRecycle  Available
  22d
[zaphod@oc6010654212 code]$ oc describe pv pv0001
Name:pv0001
Labels:  volume=pv0001
Annotations: pv.kubernetes.io/bound-by-controller: yes
Finalizers:  [kubernetes.io/pv-protection]
StorageClass:
Status:  Bound
Claim:   openshift-image-registry/crc-image-registry-storage
Reclaim Policy:  Recycle
Access Modes:RWO,ROX,RWX
VolumeMode:  Filesystem
Capacity:100Gi
Node Affinity:   
Message:
Source:
Type:  HostPath (bare host directory volume)
Path:  /mnt/pv-data/pv0001
HostPathType:
Events:
[zaphod@oc6010654212 code]$ ls -l /mnt/pv-data/pv0001
ls: cannot access /mnt/pv-data/pv0001: No such file or directory
[zaphod@oc6010654212 code]$ ls -l /mnt
total 0

What gives? Where is CRC actually storing the data in its registry,
etc? More importantly, if I want to use one of those unbound pv's for
applications, can I?

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

cronjobs - how does this work?

[Just Marvin]

Hi,

 I'm poring through the text at
https://docs.openshift.com/container-platform/4.2/nodes/jobs/nodes-nodes-jobs.html#nodes-nodes-jobs-creating-cron_nodes-nodes-jobs
.
Should I interpret spec.jobTemplate.spec.template.spec.containers.command
as a command that exists within the container specified
by cronjob.spec.jobTemplate.spec.template.spec.containers.image? I just
tried spinning up an openjdk-11-rhel7 image (by itself, using new-app) and
it refused to start up because it is coded to expect some main class /
other entrypoint specified to it. If I wanted to run java code in a batch
process, would this (or similar) containers be the right approach - i.e do
a docker / s2i build with it to add in my code and have it be executed? In
that case, should I simply not specify a command in the CronJob yaml,
because the container is already geared to run the command I need on launch?

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

Re: connection to CRC from CRS

[Just Marvin]

Gerard,

The console, for me, isn't at the hostname you mentioned. What you've
specified is my api server hostname.

[zaphod@oc6010654212 ~]$ oc get route --all-namespaces | grep console
openshift-console  console
console-openshift-console.apps-crc.testing   console
  https  reencrypt/Redirect None
openshift-console  downloads
downloads-openshift-console.apps-crc.testing downloads
  http   edge/Redirect  None

I _am_ able to login at console-openshift-console.apps-crc.testing as
kubeadmin.

Regards,
Marvin

On Sun, Nov 17, 2019 at 9:08 PM Gerard Braad  wrote:

> Hi,
>
> not sure why this wouldn't work. You are however able to login from the
> console/dashboard?
> (To make sure the hostname gets resolved; api.crc.testing)
>
> Since CRC is a full OpenShift 4.x installation without specific
> configuration, it would behave the same as any other OpenShift 4.x install.
> Have you been able to verify if the connector works with a OpenShift
> installer deployed cluster, like on AWS or other cloud provider?
>
> regards,
>
>
> Gerard
>
> On Mon, Nov 18, 2019 at 9:18 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Any takers on this question?
>>
>> On Sun, Nov 10, 2019 at 11:52 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>
>Gerard Braad | http://gbraad.nl
>[ Doing Open Source Matters ]
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

external ips - seems like handwaving in docs

[Just Marvin]

Hi,


https://docs.openshift.com/container-platform/4.2/networking/configuring-ingress-cluster-traffic/configuring-ingress-cluster-traffic-service-external-ip.html#nw-creating-project-and-service_configuring-ingress-cluster-traffic-service-external-ip
 .

Step 4 seems like magic. When I do that on my local CRC install, I get
this:

[zaphod@oc6010654212 Downloads]$ oc get svc -n openshift-ingress
NAME  TYPECLUSTER-IP   EXTERNAL-IP
PORT(S)   AGE
router-internal-default   ClusterIP   172.30.165.244   
 80/TCP,443/TCP,1936/TCP   18d
[zaphod@oc6010654212 Downloads]$

Which is what I would have expected to see. Where is that
"router-default" entry coming from? I've added an external ip to the crc
device, so I think I've met the pre-requisites. Whats the step that I'm
missing?

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

Re: sftp service on cluster - how to do it

[Just Marvin]

Tobias,

I _will_ have access to load balancers if needed, but at the moment, I
need to understand how it works. Assume that I do: what exactly does "proxy
to the internal sftp service" mean? I assume "sftp service" would be the
service that I set up, but which piece is the proxy? I don't see that load
balancer and proxy functions as being the same, so it seems like you are
talking about a third piece. What piece is that?

Regards,
Marvin

On Sun, Nov 17, 2019 at 1:30 PM Tobias Florek  wrote:

> Hi!
>
> I assume you don't have easy access to load balancers, because that
> would be easiest.  Just proxy to the internal sftp service.
>
> If you don't I have used Nodeport service in the past.  You will lose
> the nice port 22 though.  If you control the node's ssh daemon, you can
> also use ProxyJumps.  Be sure to lock down ssh for the users though.
>
> Cheers,
>  Tobias Florek
>
> ___
> 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: connection to CRC from CRS

[Just Marvin]

Hi,

One more detail that perhaps need to be addressed:

[image: image.png]

That oc binary came from the CRC install, so not sure why CRS is
unhappy.

Regards,
Marvin

On Sun, Oct 13, 2019 at 10:17 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> I'm using CodeReady Studio, and trying to point to my CRC install
> (which I assume should work - please let me know if that is a misguided
> notion). Here is what I get with the developer/developer oc login:
>
> [image: image.png]
>
> How do I fix this problem?
>
> Regards,
> Marvin
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

connection to CRC from CRS

[Just Marvin]

Hi,

I'm using CodeReady Studio, and trying to point to my CRC install
(which I assume should work - please let me know if that is a misguided
notion). Here is what I get with the developer/developer oc login:

[image: image.png]

How do I fix this problem?

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

Re: [crc] expired certs

[Just Marvin]

Gerard,

That worked! Thanks!

Regards,
Marvin

On Sun, Oct 13, 2019 at 9:48 AM Gerard Braad  wrote:

> > ERRO Error occurred: Error creating host: Error creating the VM. Error
> creating machine: Error in driver during machine creation: virError(Code=9,
> Domain=20, Message='operation failed: domain 'crc' already exists with uuid
> af77791e-7b48-41a2-8a55-2b2af884c1c7')
>
> The error you get is related to an incomplete definition of the VM. it
> is best to use `crc delete` followed by `crc start`. Your VMM will
> keep state outside of the crc folder which is out of sync due to the
> delete action.
>
> > FATA Bundle 'crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle'
> was requested, but loaded VM is using 'crc_libvirt_4.1.11.crcbundle'
>
> This indicates you have a VM with an older bundle, but requested to
> use a new version (as you started to use a new download). This can be
> resolved with a `crc delete`.
>
> In newer versions, to be available hopefully soon, these messages will
> be clearer as they contain instructions on how to proceed.
>
>
> Gerard
>
> On Sun, Oct 13, 2019 at 9:27 PM Just Marvin
>  wrote:
> >
> > Hi,
> >
> > Got this when I tried with a new download:
> >
> > [zaphod@oc6010654212 Downloads]$ crc start
> > INFO Checking if running as non-root
> > INFO Checking if oc binary is cached
> > INFO Checking if Virtualization is enabled
> > INFO Checking if KVM is enabled
> > INFO Checking if libvirt is installed
> > INFO Checking if user is part of libvirt group
> > INFO Checking if libvirt is enabled
> > INFO Checking if libvirt daemon is running
> > INFO Checking if a supported libvirt version is installed
> > INFO Checking if crc-driver-libvirt is installed
> > INFO Checking if libvirt 'crc' network is available
> > INFO Checking if libvirt 'crc' network is active
> > INFO Checking if NetworkManager is installed
> > INFO Checking if NetworkManager service is running
> > INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
> > INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
> > FATA Bundle 'crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle'
> was requested, but loaded VM is using 'crc_libvirt_4.1.11.crcbundle'
> > [zaphod@oc6010654212 Downloads]$
> >
> > I deleted the $HOME/.crc dir and tried again. This time, I got this:
> >
> > INFO Extracting bundle:
> crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle ...
> > INFO Creating CodeReady Containers VM for OpenShift
> 4.2.0-0.nightly-2019-09-26-192831...
> > ERRO Error occurred: Error creating host: Error creating the VM. Error
> creating machine: Error in driver during machine creation: virError(Code=9,
> Domain=20, Message='operation failed: domain 'crc' already exists with uuid
> af77791e-7b48-41a2-8a55-2b2af884c1c7')
> >
> > How do I fix this?
> >
> > Regards,
> > Marvin
> >
> >
> > On Sun, Oct 13, 2019 at 9:22 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I didn't see any mention of this in the docs, but a reinstall from
> a new download only works if one deletes the $HOME/.crc directory.
> Otherwise, one gets failure messages such as:
> >>
> >> [zaphod@oc6010654212 Downloads]$ crc start
> >> INFO Checking if running as non-root
> >> INFO Checking if oc binary is cached
> >> INFO Checking if Virtualization is enabled
> >> INFO Checking if KVM is enabled
> >> INFO Checking if libvirt is installed
> >> INFO Checking if user is part of libvirt group
> >> INFO Checking if libvirt is enabled
> >> INFO Checking if libvirt daemon is running
> >> INFO Checking if a supported libvirt version is installed
> >> INFO Checking if crc-driver-libvirt is installed
> >> INFO Checking if libvirt 'crc' network is available
> >> INFO Checking if libvirt 'crc' network is active
> >> INFO Checking if NetworkManager is installed
> >> INFO Checking if NetworkManager service is running
> >> INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
> >> INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
> >> FATA Bundle 'crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle'
> was requested, but loaded VM is using 'crc_libvirt_4.1.11.crcbundle'
> >> [zaphod@oc6010654212 Downloads]$
> >>
> >> Regards,
> >> Marvin
> >>
> >> On Sat, Oct 12, 2019 at 3:57 PM Daniel Veillard 
> wrote:
> >>>
> >>> On Sat, Oct

Re: [crc] expired certs

[Just Marvin]

Hi,

Got this when I tried with a new download:

[zaphod@oc6010654212 Downloads]$ crc start
INFO Checking if running as non-root
INFO Checking if oc binary is cached
INFO Checking if Virtualization is enabled
INFO Checking if KVM is enabled
INFO Checking if libvirt is installed
INFO Checking if user is part of libvirt group
INFO Checking if libvirt is enabled
INFO Checking if libvirt daemon is running
INFO Checking if a supported libvirt version is installed
INFO Checking if crc-driver-libvirt is installed
INFO Checking if libvirt 'crc' network is available
INFO Checking if libvirt 'crc' network is active
INFO Checking if NetworkManager is installed
INFO Checking if NetworkManager service is running
INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
FATA Bundle 'crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle' was
requested, but loaded VM is using 'crc_libvirt_4.1.11.crcbundle'
[zaphod@oc6010654212 Downloads]$

I deleted the $HOME/.crc dir and tried again. This time, I got this:

INFO Extracting bundle:
crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle ...
INFO Creating CodeReady Containers VM for OpenShift
4.2.0-0.nightly-2019-09-26-192831...
ERRO Error occurred: Error creating host: Error creating the VM. Error
creating machine: Error in driver during machine creation: virError(Code=9,
Domain=20, Message='operation failed: domain 'crc' already exists with uuid
af77791e-7b48-41a2-8a55-2b2af884c1c7')

How do I fix this?

Regards,
Marvin


On Sun, Oct 13, 2019 at 9:22 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Hi,
>
> I didn't see any mention of this in the docs, but a reinstall from a
> new download only works if one deletes the $HOME/.crc directory. Otherwise,
> one gets failure messages such as:
>
> [zaphod@oc6010654212 Downloads]$ crc start
> INFO Checking if running as non-root
> INFO Checking if oc binary is cached
> INFO Checking if Virtualization is enabled
> INFO Checking if KVM is enabled
> INFO Checking if libvirt is installed
> INFO Checking if user is part of libvirt group
> INFO Checking if libvirt is enabled
> INFO Checking if libvirt daemon is running
> INFO Checking if a supported libvirt version is installed
> INFO Checking if crc-driver-libvirt is installed
> INFO Checking if libvirt 'crc' network is available
> INFO Checking if libvirt 'crc' network is active
> INFO Checking if NetworkManager is installed
> INFO Checking if NetworkManager service is running
> INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
> INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
> FATA Bundle 'crc_libvirt_4.2.0-0.nightly-2019-09-26-192831.crcbundle' was
> requested, but loaded VM is using 'crc_libvirt_4.1.11.crcbundle'
> [zaphod@oc6010654212 Downloads]$
>
> Regards,
> Marvin
>
> On Sat, Oct 12, 2019 at 3:57 PM Daniel Veillard 
> wrote:
>
>> On Sat, Oct 12, 2019 at 01:30:36PM -0400, John Mazzitelli wrote:
>> > You need to grab a new version. The images expire 30 days after they
>> are released.
>> >
>> > See the CRC readme for details on this:
>> https://github.com/code-ready/crc/blob/master/README.adoc
>>
>>   Right, the team is working to find a solution, but at this point
>> you will have to use a new build.
>>
>> Daniel
>>
>> > - Original Message -
>> > > Hi,
>> > >
>> > > Getting this, this morning:
>> > >
>> > > INFO Checking if CRC bundle is cached in '$HOME/.crc'
>> > > INFO Starting stopped VM ...
>> > > INFO Verifying validity of the cluster certificates ...
>> > > ERRO Error occurred: Certs have expired, they were valid till: 09 Oct
>> 19
>> > > 12:47 +
>> > > [zaphod@oc6010654212 ~]$
>> > >
>> > > How do I fix this?
>> > >
>> > > Regards,
>> > > Marvin
>> > >
>> > > ___
>> > > 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
>> >
>>
>> --
>> Daniel Veillard  | Red Hat Developers Tools
>> http://developer.redhat.com/
>> veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
>> http://veillard.com/ | virtualization library  http://libvirt.org/
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

[crc] expired certs

[Just Marvin]

Hi,

 Getting this, this morning:

INFO Checking if CRC bundle is cached in '$HOME/.crc'
INFO Starting stopped VM ...
INFO Verifying validity of the cluster certificates ...
ERRO Error occurred: Certs have expired, they were valid till: 09 Oct 19
12:47 +
[zaphod@oc6010654212 ~]$

How do I fix this?

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

Re: istio pods

[Just Marvin]

Samuel,

Well that was it. I had screwed up the machine type definitions in the
install-config.yaml (I thought I was specifying the higher capacities for
the worker, but I made the changes in the master section). Duh.

Retrying

Regards,
Marvin

On Thu, Oct 10, 2019 at 8:08 AM Samuel Martín Moro 
wrote:

> Hi,
>
> Looking at that node labels, we can see the instance type being used is
> m4.large, and not c5.xlarge.
> So it would be normal to only see 2 CPUs instead of 4.
> How did you change your instances sizes? Editing your install-config.yaml?
> Can you show us? (you can remove any sensitive data, like pullSecrets)
>
> Regards.
>
> On Thu, Oct 10, 2019 at 1:53 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Samuel,
>>
>> See below, the output from "oc describe node " for one of my
>> worker nodes. In particular, I'm interested in the "Capacity" and
>> "Allocatable" sections. In the Capacity section, it says that this is 2
>> CPUs. When I first noticed this, I had defined the workers using c5-xlarge
>> machines - which have 4 vpcus. I thought that maybe OpenShift itself is
>> reserving 2 CPUs for itself. But I then rebuilt the cluster with c5-2xlarge
>> machines, and the output you see, below, is from that. It shows 2 CPUs as
>> well. So this seems like OpenShift isn't recognizing the additional
>> hardware. How do I fix this?
>>
>> name:   ip-10-0-156-206.us-west-1.compute.internal
>> Roles:  worker
>> Labels: beta.kubernetes.io/arch=amd64
>> beta.kubernetes.io/instance-type=m4.large
>> beta.kubernetes.io/os=linux
>> failure-domain.beta.kubernetes.io/region=us-west-1
>> failure-domain.beta.kubernetes.io/zone=us-west-1b
>> kubernetes.io/arch=amd64
>> kubernetes.io/hostname=ip-10-0-156-206
>> kubernetes.io/os=linux
>> node-role.kubernetes.io/worker=
>> node.openshift.io/os_id=rhcos
>> Annotations:machine.openshift.io/machine:
>> openshift-machine-api/two-4z45k-worker-us-west-1b-t4dln
>> machineconfiguration.openshift.io/currentConfig:
>> rendered-worker-f4169460716c78be83ccb2609dd91fc3
>> machineconfiguration.openshift.io/desiredConfig:
>> rendered-worker-f4169460716c78be83ccb2609dd91fc3
>> machineconfiguration.openshift.io/state: Done
>>
>> volumes.kubernetes.io/controller-managed-attach-detach: true
>> CreationTimestamp:  Thu, 10 Oct 2019 07:30:18 -0400
>> Taints: 
>> Unschedulable:  false
>> Conditions:
>>   Type Status  LastHeartbeatTime
>> LastTransitionTimeReason   Message
>>    --  -
>> ----   ---
>>   MemoryPressure   False   Thu, 10 Oct 2019 07:46:01 -0400   Thu, 10 Oct
>> 2019 07:30:18 -0400   KubeletHasSufficientMemory   kubelet has sufficient
>> memory available
>>   DiskPressure False   Thu, 10 Oct 2019 07:46:01 -0400   Thu, 10 Oct
>> 2019 07:30:18 -0400   KubeletHasNoDiskPressure kubelet has no disk
>> pressure
>>   PIDPressure  False   Thu, 10 Oct 2019 07:46:01 -0400   Thu, 10 Oct
>> 2019 07:30:18 -0400   KubeletHasSufficientPID  kubelet has sufficient
>> PID available
>>   ReadyTrueThu, 10 Oct 2019 07:46:01 -0400   Thu, 10 Oct
>> 2019 07:31:19 -0400   KubeletReady kubelet is posting ready
>> status
>> Addresses:
>>   InternalIP:   10.0.156.206
>>   Hostname: ip-10-0-156-206.us-west-1.compute.internal
>>   InternalDNS:  ip-10-0-156-206.us-west-1.compute.internal
>> Capacity:
>>  attachable-volumes-aws-ebs:  39
>>  cpu: 2
>>  hugepages-1Gi:   0
>>  hugepages-2Mi:   0
>>  memory:  8162888Ki
>>  pods:250
>> Allocatable:
>>  attachable-volumes-aws-ebs:  39
>>  cpu: 1500m
>>  hugepages-1Gi:   0
>>  hugepages-2Mi:   0
>>  memory:  7548488Ki
>>  pods:250
>> System Info:
>>  Machine ID:  23efe37e2b244bd788bb8575cd340bfd
>>  System UUID:
>> ec25c230-d02c-99cf-0540-bad276c8cc73
>>  Boot ID:
>> 1f3a064f-a24e-4bdf-b6b0-c7fd3019757e
>>  Kern

Re: istio pods

[Just Marvin]

   16m
  openshift-machine-config-operator   machine-config-daemon-6ht2m
  20m (1%)  0 (0%)  50Mi (0%)0 (0%) 15m
  openshift-marketplace
certified-operators-5cb88dd798-lcfvc10m (0%)  0 (0%)  100Mi
(1%)   0 (0%) 17m
  openshift-marketplace
community-operators-7f8987f496-8rgzq10m (0%)  0 (0%)  100Mi
(1%)   0 (0%) 17m
  openshift-marketplace   redhat-operators-cd495bc4f-fcm5t
   10m (0%)  0 (0%)  100Mi (1%)   0 (0%) 17m
  openshift-monitoringalertmanager-main-1
  100m (6%) 100m (6%)   225Mi (3%)   25Mi (0%)  12m
  openshift-monitoring
 kube-state-metrics-6b66989cb7-nlqbm 30m (2%)  0 (0%)
 120Mi (1%)   0 (0%) 17m
  openshift-monitoringnode-exporter-bhrhz
  10m (0%)  0 (0%)  20Mi (0%)0 (0%) 16m
  openshift-monitoring
 openshift-state-metrics-6bf647b484-sfgjs120m (8%) 0 (0%)
 190Mi (2%)   0 (0%) 17m
  openshift-monitoring
 prometheus-adapter-66d6b69459-bcq5p 10m (0%)  0 (0%)  20Mi
(0%)0 (0%) 13m
  openshift-monitoringprometheus-k8s-1
   430m (28%)200m (13%)  1134Mi (15%) 50Mi (0%)  14m
  openshift-multusmultus-jlmwx
   10m (0%)  0 (0%)  150Mi (2%)   0 (0%) 16m
  openshift-sdn   ovs-hdml2
  200m (13%)0 (0%)  400Mi (5%)   0 (0%) 16m
  openshift-sdn   sdn-vwh22
  100m (6%) 0 (0%)  200Mi (2%)   0 (0%) 16m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  ResourceRequests  Limits
    --
  cpu 1390m (92%)   300m (20%)
  memory  3451Mi (46%)  587Mi (7%)
  ephemeral-storage   0 (0%)0 (0%)
  attachable-volumes-aws-ebs  0 0
Events:   



On Wed, Oct 9, 2019 at 8:30 AM Samuel Martín Moro  wrote:

> You have two master nodes? You'ld rather go with 1 or 3. With 2 masters,
> your etcd quorum is 2. If you lose a master, the API would be unavailable.
>
> Now ... c5-xlarge should be fine.
> Not sure why your console doesn't show everything (and not familiar with
> that dashboard yet). as a wild guess, probably some delay collecting
> metrics. Though you should see something, eventually.
>
> If you use "oc describe node ", you should see the reservations
> (requests & limits) for that node.
> Might be able to figure out what's eating up your resources.
>
> Depending on what openshift components you're deploying, you may already
> be using quite a lot.
> Especially if you don't have infra nodes, and did deploy EFK and/or
> hawkular/cassandra. Prometheus could use some resources as well.
> Meanwhile, istio itself can ship with more or less components, ...
>
> If using EFK: you may be able to lower resources requests/limits for
> ElasticSearch
> If using Hawkular: same remark regarding Cassandra
> Hard to say, without seeing it. But you can probably free up some
> resources here and there.
>
>
> Good luck,
>
> Regards.
>
> On Wed, Oct 9, 2019 at 1:47 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Samuel,
>>
>> So it is CPU. But, I destroyed the cluster, gave it machines with
>> twice as much memory, retried and got the same problem:
>>
>> Events:
>>   Type ReasonAge  From
>> Message
>>    -- 
>> ---
>>   Warning  FailedScheduling  16s (x4 over 3m12s)  default-scheduler  0/4
>> nodes are available: 2 Insufficient cpu, 2 node(s) had taints that the pod
>> didn't tolerate.
>>
>> I'm guessing that the two pods with taints are the two master nodes,
>> but the other two are c5-xlarge machines. But here is maybe a relevant
>> observation. As soon as I log into the cluster, I see this on my main
>> dashboard.
>>
>> [image: image.png]
>>
>> Is there perhaps a problem with the CPU resource monitoring that is
>> causing my problems?
>>
>> Regards,
>> Marvin
>>
>> On Sun, Oct 6, 2019 at 3:52 PM Samuel Martín Moro 
>> wrote:
>>
>>> you can use "oc describe pod ", to figure out what's going on
>>> with your pod.
>>> could be that you're out of cpu/memory.
>>>
>>> Regards.
>>>
>>> On Sun, Oct 6, 2019 at 9:27 PM Just Marvin <
>>> marvin.the.cynical.ro...@gmail.com> 

Re: istio pods

[Just Marvin]

Samuel,

So it is CPU. But, I destroyed the cluster, gave it machines with twice
as much memory, retried and got the same problem:

Events:
  Type ReasonAge  From   Message
   --    ---
  Warning  FailedScheduling  16s (x4 over 3m12s)  default-scheduler  0/4
nodes are available: 2 Insufficient cpu, 2 node(s) had taints that the pod
didn't tolerate.

I'm guessing that the two pods with taints are the two master nodes,
but the other two are c5-xlarge machines. But here is maybe a relevant
observation. As soon as I log into the cluster, I see this on my main
dashboard.

[image: image.png]

Is there perhaps a problem with the CPU resource monitoring that is
causing my problems?

Regards,
Marvin

On Sun, Oct 6, 2019 at 3:52 PM Samuel Martín Moro  wrote:

> you can use "oc describe pod ", to figure out what's going on
> with your pod.
> could be that you're out of cpu/memory.
>
> Regards.
>
> On Sun, Oct 6, 2019 at 9:27 PM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> [zaphod@oc3027208274 ocp4.2-aws]$ oc get pods
>> NAME  READY   STATUSRESTARTS   AGE
>> istio-citadel-7cb44f4bb-tccql 1/1 Running   0  9m35s
>> istio-galley-75599dbc67-b4mgx 1/1 Running   0  8m41s
>> istio-policy-56476c984b-c7t8j 0/2 *Pending*   0  8m23s
>> istio-telemetry-d5bbd7d7b-v8kjq   0/2 *Pending*   0  8m24s
>> jaeger-5d9dfdfb67-mv8mp   2/2 Running   0  8m45s
>> prometheus-685bdbdc45-hmb9f   2/2 Running   0  9m17s
>> [zaphod@oc3027208274 ocp4.2-aws]$
>>
>> The pods in Pending state don't seem to be moving forward. The
>> operator logs aren't showing anything informative about why this might be.
>> Is this normal, or if there is a problem, and if so, how would I figure out
>> the cause?
>>
>> Regards,
>> Marvin
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>
>
> --
> Samuel Martín Moro
> {EPITECH.} 2011
>
> "Nobody wants to say how this works.
>  Maybe nobody knows ..."
>   Xorg.conf(5)
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: ocp4 cluster fails to initialize on GCP

[Just Marvin]

Trevor,

Found this bit in host_service_logs/masters/kubelet_service.log

Oct 06 11:00:34 I1006 11:00:34.4365071201 clientconn.go:796]
ClientConn switching balancer to "pick_first"
Oct 06 11:00:34 I1006 11:00:34.4365351201 file.go:200] Reading
config file "/etc/kubernetes/manifests/gcp-routes-control
ler.yaml"
Oct 06 11:00:34 1006 11:00:34.4375371201
balancer_conn_wrappers.go:131] pickfirstBalancer: HandleSubConnStateChange:
0xc0006d5400, CONNECTING
Oct 06 11:00:34 1006 11:00:34.4375371201
balancer_conn_wrappers.go:131] pickfirstBalancer: HandleSubConnStateChange:
0xc00075aa70, CONNECTING
Oct 06 11:00:34 I1006 11:00:34.4435221201
balancer_conn_wrappers.go:131] pickfirstBalancer: HandleSubConnStateChange:
0xc0006d5400, READY
Oct 06 11:00:34 I1006 11:00:34.4436371201
balancer_conn_wrappers.go:131] pickfirstBalancer: HandleSubConnStateChange:
0xc00075aa70, READY
Oct 06 11:00:34 E1006 11:00:34.4441731201 aws_credentials.go:77]
while getting *AWS* credentials NoCredentialProviders: no valid providers
in chain. Deprecated.
Oct 06 11:00:34  For verbose messaging see *aws*
.Config.CredentialsChainVerboseErrors

Is this a potential cause of my problems or an unrelated issue?

Regards,
Marvin

On Mon, Oct 7, 2019 at 1:01 PM W. Trevor King  wrote:

> On Mon, Oct 7, 2019 at 4:22 AM Just Marvin wrote:
> > I went with the default install-config.yaml and there were 3 worker
> nodes and 3 master node.
>
> Your must-gather only has the three control-plane nodes under
> cluster-scoped-resources/core/nodes/.  Looking at one of your compute
> Machine objects
> (namespaces/openshift-machine-api/
> machine.openshift.io/machines/one-qx6jl-w-a-xqvqv.yaml),
> shows MachineCreationSucceeded, so you should have that machine
> running.  But it hasn't joined your cluster as a schedulable node
> (likely because of the unapproved certificate signing requests in
> cluster-scoped-resources/certificates.k8s.io/).  I don't see anything
> in your openshift-cluster-machine-approver namespace (I'd expect [1]),
> not sure what's going on there yet.
>
> Cheers,
> Trevor
>
> [1]: https://github.com/openshift/cluster-machine-approver
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: ocp4 cluster fails to initialize on GCP

[Just Marvin]

Trevor,

I don't follow you. You are talking about GCP compute machines - right?
I went with the default install-config.yaml and there were 3 worker nodes
and 3 master node. See the snippet, below from the config file:

compute:
- hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3

I did observe them being up and running. And without any such machines
being available, I don't think my install would have reached 99%, so you
probably meant something else when you said "you have no compute
machines associated with your cluster". If I'm looking in the wrong
direction, please point me in the right direction.

Regards,
Marvin

On Mon, Oct 7, 2019 at 12:53 AM W. Trevor King  wrote:

> On Sun, Oct 6, 2019 at 9:35 AM Just Marvin wrote:
> > FYI - was able to use the same downloaded binaries and install
> successfully on AWS. In AWS, I do get the the widlcarded *.apps A
> record in the public hosted zone.
>
> Here's what a successful *.apps record looks like in GCP [1].  I don't
> see that in your gather.  And skimming quickly through it, seems like
> cluster-scoped-resources/certificates.k8s.io/ is full of unapproved
> certificate signing requests?  Looks like you have no compute machines
> associated with your cluster.  And without compute machines, you won't
> be able to get ingress working, as far as I'm aware (although I'm not
> all that familiar with GCP, maybe they do something different for
> ingress routing).
>
> Cheers,
> Trevor
>
> [1]:
> https://storage.googleapis.com/origin-ci-test/logs/release-openshift-ocp-installer-e2e-gcp-4.2/28/artifacts/e2e-gcp/must-gather/quay-io-openshift-release-dev-ocp-v4-0-art-dev-sha256-ce0ba52504b78358de89a0d8bc483d9d1eff3fefcbda1e43255636012dce14f7/namespaces/openshift-ingress-operator/ingress.operator.openshift.io/dnsrecords/default-wildcard.yaml
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

istio pods

[Just Marvin]

Hi,

[zaphod@oc3027208274 ocp4.2-aws]$ oc get pods
NAME  READY   STATUSRESTARTS   AGE
istio-citadel-7cb44f4bb-tccql 1/1 Running   0  9m35s
istio-galley-75599dbc67-b4mgx 1/1 Running   0  8m41s
istio-policy-56476c984b-c7t8j 0/2 *Pending*   0  8m23s
istio-telemetry-d5bbd7d7b-v8kjq   0/2 *Pending*   0  8m24s
jaeger-5d9dfdfb67-mv8mp   2/2 Running   0  8m45s
prometheus-685bdbdc45-hmb9f   2/2 Running   0  9m17s
[zaphod@oc3027208274 ocp4.2-aws]$

The pods in Pending state don't seem to be moving forward. The operator
logs aren't showing anything informative about why this might be. Is this
normal, or if there is a problem, and if so, how would I figure out the
cause?

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

Re: ocp4 cluster fails to initialize on GCP

[Just Marvin]

Hi,

FYI - was able to use the same downloaded binaries and install
successfully on AWS. In AWS, I do get the the widlcarded *.apps A
record in the public hosted zone.

Regards,
Marvin

On Sun, Oct 6, 2019 at 8:38 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Trevor,
>
> Responded to your email with the logs, but that is still pending
> moderator approval to be posted to the list (since the size of the message
> was above the size cap). While a moderator makes up his / her mind, I
> thought that I'd repeat some of my observations:
>
> E1006 11:39:34.041543   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:39:34.041641   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> W1006 11:40:12.831667   1 reflector.go:289]
> k8s.io/client-go/informers/factory.go:133: watch of *v1.ConfigMap ended
> with: too old resource version: 17351 (19676)
> W1006 11:40:30.881153   1 reflector.go:289]
> k8s.io/client-go/informers/factory.go:133: watch of *v1.ConfigMap ended
> with: too old resource version: 18133 (19758)
> E1006 11:45:13.003476   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:45:13.003613   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> W1006 11:46:25.850256   1 reflector.go:289]
> k8s.io/client-go/informers/factory.go:133: watch of *v1.ConfigMap ended
> with: too old resource version: 19478 (21246)
> E1006 11:46:26.883137   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:46:26.883217   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> W1006 11:47:00.837769   1 reflector.go:289]
> k8s.io/client-go/informers/factory.go:133: watch of *v1.ConfigMap ended
> with: too old resource version: 19826 (21404)
> W1006 11:47:03.833901   1 reflector.go:289]
> k8s.io/client-go/informers/factory.go:133: watch of *v1.Deployment ended
> with: too old resource version: 13636 (14162)
> E1006 11:47:28.977942   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:47:28.978052   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> E1006 11:47:29.001738   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:47:29.001853   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> E1006 11:47:29.031826   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:47:29.031924   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
> E1006 11:47:29.455882   1 status.go:71] RouteSyncProgressing
> FailedHost route is not available at canonical host []
> E1006 11:47:29.456081   1 controller.go:129] {Console Console} failed
> with: route is not available at canonical host []
>
>  This is a default install with three masters. Previously, I had done
> an install with one master, and even though that was hanging, the console
> route had been defined (and so, I imagine, there would have been an A
> record set up in DNS). Currently, I see an A record for the master, but not
> for the console. I'm wondering if there is perhaps a screwup on my DNS
> setup that is contributing to the problem.
>
> As of right now (probably another 30 mins past the install timing
> out), I still see the following messages in the cluster version operator
> log:
>
> I1006 12:31:16.462865   1 sync_worker.go:745] Update error 294 of 432:
> ClusterOperatorNotAvailable Cluster operator console has not yet reported
> success (*errors.errorString: cluster operator console is not done; it is
> available=false, progressing=true, degraded=false)
> I1006 12:31:16.462876   1 sync_worker.go:745] Update error 135 of 432:
> ClusterOperatorNotAvailable Cluster operator authentication is still
> updating (*errors.errorString: cluster operator authentication is still
> updating)
> I1006 12:31:16.462884   1 sync_worker.go:745] Update error 260 of 432:
> ClusterOperatorNotAvailable Cluster operator monitoring is still updating
> (*errors.errorString: cluster operator monitoring is still updating)
> I1006 12:31:16.462890   1 sync_worker.go:745] Update error 183 of 432:
> ClusterOperatorNotAvailable Cluster operator ingress is still updating
> (*errors.errorString: cluster operator ingress is still updating)
> I1006 12:31:16.462897 

ocp4 cluster fails to initialize on GCP

[Just Marvin]

Hi,

Here is what I get:

aphod@oc3027208274 ocp4.2]$ ./openshift-install create cluster
INFO Consuming "Install Config" from target directory
INFO Creating infrastructure resources...
INFO Waiting up to 30m0s for the Kubernetes API at
https://api.one.discworld.a.random.domain:6443...
INFO API v1.14.6+70f9554 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO Destroying the bootstrap resources...
INFO Waiting up to 30m0s for the cluster at
https://api.one.discworld.a.random.domain:6443 to initialize...
FATAL failed to initialize the cluster: Working towards
4.2.0-0.nightly-2019-10-01-210901: 99% complete

[zaphod@oc3027208274 ocp4.2]$ tail -f .openshift_install.log
time="2019-10-05T13:31:47-04:00" level=debug msg="Still waiting for the
cluster to initialize: Working towards 4.2.0-0.nightly-2019-10-01-210901:
99% complete"
time="2019-10-05T13:34:32-04:00" level=debug msg="Still waiting for the
cluster to initialize: Some cluster operators are still updating:
authentication, console, image-registry, ingress, monitoring"
time="2019-10-05T13:37:47-04:00" level=debug msg="Still waiting for the
cluster to initialize: Working towards 4.2.0-0.nightly-2019-10-01-210901:
99% complete"
time="2019-10-05T13:40:32-04:00" level=debug msg="Still waiting for the
cluster to initialize: Some cluster operators are still updating:
authentication, console, image-registry, ingress, monitoring"
time="2019-10-05T13:43:47-04:00" level=debug msg="Still waiting for the
cluster to initialize: Working towards 4.2.0-0.nightly-2019-10-01-210901:
99% complete"
time="2019-10-05T13:46:17-04:00" level=debug msg="Still waiting for the
cluster to initialize: Some cluster operators are still updating:
authentication, console, image-registry, ingress, monitoring"
time="2019-10-05T13:50:02-04:00" level=debug msg="Still waiting for the
cluster to initialize: Working towards 4.2.0-0.nightly-2019-10-01-210901:
99% complete"
time="2019-10-05T13:52:47-04:00" level=debug msg="Still waiting for the
cluster to initialize: Some cluster operators are still updating:
authentication, console, image-registry, ingress, monitoring"
time="2019-10-05T13:56:02-04:00" level=debug msg="Still waiting for the
cluster to initialize: Working towards 4.2.0-0.nightly-2019-10-01-210901:
99% complete"
time="2019-10-05T13:56:49-04:00" level=fatal msg="failed to initialize the
cluster: Working towards 4.2.0-0.nightly-2019-10-01-210901: 99% complete"

How do I track down what went wrong. And at this point, is it just a
matter of waiting for a while? Suppose I let it go for a few hours, will
there be a way to see if the initialization did complete?

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

Re: [OKD/OCP v4]: deployment on a single node using CodeReady Container

[Just Marvin]

Forgot to add the link for the reference:

[1] https://code-ready.github.io/crc/ - section 1.4

On Sun, Sep 22, 2019 at 3:35 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Daniel,
>
> TBH, I didn't follow a lot of that. But the bit that I did get was
> your recommendation to try the full OCP install instead of CRC. I'll give
> that a try.
>
> FYI, I did enable nested virtualization on GCP, and progressed quite a
> bit further. I will note that the install instructions [1] need to list
> qemu-kvm as a packaged to be installed on Centos7. But in the end, I failed
> at this point:
>
> INFO Loading bundle: crc_libvirt_4.1.11.crcbundle ...
> INFO Extracting bundle: crc_libvirt_4.1.11.crcbundle ...
> INFO Creating VM ...
> INFO Verifying validity of the cluster certificates ...
> INFO Check internal and public dns query ...
> INFO Copying kubeconfig file to instance dir ...
> INFO Adding user's pull secret and cluster ID ...
> ERRO Error occurred: Failed to update user pull secret or cluster ID: ssh
> command error:
> command : timeout 80 bash -c 'until oc --config /tmp/kubeconfig replace -f
> /tmp/pull-secret.yaml 2>/dev/null 1>&2; \
> do echo "Waiting for recovery apiserver to come up."; sleep 1; done'
> err : exit status 124
> output  : Waiting for recovery apiserver to come up.
> Waiting for recovery apiserver to come up.
> Waiting for recovery apiserver to come up.
>
> Not sure what is going on. Probably, as you mentioned, networking
> hasn't been set up in a fashion that allows the ssh to work.
>
> Regards,
> Marvin
>
> On Sat, Sep 21, 2019 at 3:36 AM Daniel Veillard 
> wrote:
>
>> On Fri, Sep 20, 2019 at 04:47:09PM -0400, Just Marvin wrote:
>> > Daniel,
>> >
>> > I appreciate the insights into the challenges. The goal that you
>> > stated, though, is going to be hard to achieve with a limitation of
>> > bare-metal only for developers. See the other thread in this forum for
>> the
>> > service mesh. The kind of resource requirements, as stated in that
>> thread,
>> > needed to do something like that on CRC will rarely be found on a
>> developer
>> > laptop. So, for someone like me, the choice really boils down to
>> running a
>> > full-fledged OCP on a dedicated machine / VM if I want to try out /
>> > experience something like the OpenShift Service Mesh. And such dedicated
>> > machines / VMs are hard to come by unless one uses the public cloud.
>> So, I
>> > hope that running in such an environment becomes easier for CRC.
>> >
>> > Regards,
>> > Marvin
>>
>>Hi Marvin,
>>
>>   Hum, there is something I don't understand,
>> if you are going to use a dedicated machine to run your OCP workload, why
>> not run the full install then. We made a number of choice to be able to
>> adapt to the laptop situation:
>>   - single node, hence only one VM to minimize the memory footprint
>> and trashing between competing VMs
>>   - pre-baked installation, so that CRC is usable nearly immediately
>> after download compared to the time it would take to run the installer
>> fetch everything and run the install process on a laptop hard drive
>>   - disable a number of operators which are part of a full fledged install
>> of OCP to reduce the memory footprint, most notably the telemetry
>> part.
>>
>>   Some of those I would avoid if I were to install my devel cluster on
>> a 64 GB tower I have laying around in my office. The install would have to
>> be done once, not on my main machine so no big deal if it takes one hour,
>> it would be closer in behaviour to a full cluster on AWS too.
>>
>>   We added back last year the minishift --remote for those use case
>> because
>> TBH running the Ansible playbook for 3.x on a random Linux install was a
>> bit
>> of a challenge. But for CRC  that's not really possible, we don't run the
>> installer, it's pre-cooked, and requires the CoreOS base, so I don't see
>> how we could ever do this.
>>
>>   One of the scenario we could try is to take the installed bundle VM
>> content
>> and try to run it inside a container instead of a VM, but that means no
>> guarantee on the kernel behaviour, nor system library, and sorting out
>> networking would likely be case by case.
>>
>>   I wonder if the real solution isn't for those case to make it easier
>> for people to run the libvirt side of the installer directly. Another
>> option
>> is the Ansible route, though TBH I don't know how well that's 

Re: [OKD/OCP v4]: deployment on a single node using CodeReady Container

[Just Marvin]

Daniel,

TBH, I didn't follow a lot of that. But the bit that I did get was your
recommendation to try the full OCP install instead of CRC. I'll give that a
try.

FYI, I did enable nested virtualization on GCP, and progressed quite a
bit further. I will note that the install instructions [1] need to list
qemu-kvm as a packaged to be installed on Centos7. But in the end, I failed
at this point:

INFO Loading bundle: crc_libvirt_4.1.11.crcbundle ...
INFO Extracting bundle: crc_libvirt_4.1.11.crcbundle ...
INFO Creating VM ...
INFO Verifying validity of the cluster certificates ...
INFO Check internal and public dns query ...
INFO Copying kubeconfig file to instance dir ...
INFO Adding user's pull secret and cluster ID ...
ERRO Error occurred: Failed to update user pull secret or cluster ID: ssh
command error:
command : timeout 80 bash -c 'until oc --config /tmp/kubeconfig replace -f
/tmp/pull-secret.yaml 2>/dev/null 1>&2; \
do echo "Waiting for recovery apiserver to come up."; sleep 1; done'
err : exit status 124
output  : Waiting for recovery apiserver to come up.
Waiting for recovery apiserver to come up.
Waiting for recovery apiserver to come up.

Not sure what is going on. Probably, as you mentioned, networking
hasn't been set up in a fashion that allows the ssh to work.

Regards,
Marvin

On Sat, Sep 21, 2019 at 3:36 AM Daniel Veillard  wrote:

> On Fri, Sep 20, 2019 at 04:47:09PM -0400, Just Marvin wrote:
> > Daniel,
> >
> > I appreciate the insights into the challenges. The goal that you
> > stated, though, is going to be hard to achieve with a limitation of
> > bare-metal only for developers. See the other thread in this forum for
> the
> > service mesh. The kind of resource requirements, as stated in that
> thread,
> > needed to do something like that on CRC will rarely be found on a
> developer
> > laptop. So, for someone like me, the choice really boils down to running
> a
> > full-fledged OCP on a dedicated machine / VM if I want to try out /
> > experience something like the OpenShift Service Mesh. And such dedicated
> > machines / VMs are hard to come by unless one uses the public cloud. So,
> I
> > hope that running in such an environment becomes easier for CRC.
> >
> > Regards,
> > Marvin
>
>Hi Marvin,
>
>   Hum, there is something I don't understand,
> if you are going to use a dedicated machine to run your OCP workload, why
> not run the full install then. We made a number of choice to be able to
> adapt to the laptop situation:
>   - single node, hence only one VM to minimize the memory footprint
> and trashing between competing VMs
>   - pre-baked installation, so that CRC is usable nearly immediately
> after download compared to the time it would take to run the installer
> fetch everything and run the install process on a laptop hard drive
>   - disable a number of operators which are part of a full fledged install
> of OCP to reduce the memory footprint, most notably the telemetry part.
>
>   Some of those I would avoid if I were to install my devel cluster on
> a 64 GB tower I have laying around in my office. The install would have to
> be done once, not on my main machine so no big deal if it takes one hour,
> it would be closer in behaviour to a full cluster on AWS too.
>
>   We added back last year the minishift --remote for those use case because
> TBH running the Ansible playbook for 3.x on a random Linux install was a
> bit
> of a challenge. But for CRC  that's not really possible, we don't run the
> installer, it's pre-cooked, and requires the CoreOS base, so I don't see
> how we could ever do this.
>
>   One of the scenario we could try is to take the installed bundle VM
> content
> and try to run it inside a container instead of a VM, but that means no
> guarantee on the kernel behaviour, nor system library, and sorting out
> networking would likely be case by case.
>
>   I wonder if the real solution isn't for those case to make it easier
> for people to run the libvirt side of the installer directly. Another
> option
> is the Ansible route, though TBH I don't know how well that's supported
> in 4.x
>
>Hope this makes sense,
>
> Daniel
>
> > On Fri, Sep 20, 2019 at 9:21 AM Daniel Veillard 
> wrote:
> >
> > > On Thu, Sep 19, 2019 at 10:00:40PM -0300, Fernando Lozano wrote:
> > > > Yes, bare-metal only.
> > >
> > >  Hi,
> > >
> > > I'm the manager for the CRC group.
> > > We indeed tested it only on bare metal. The goal is really to provide
> > > a quick and easy way for a developer to run OCP 4.x on their laptop.
> > > That said as Joel suggested you may try to enable nest

CRC and OpenShift Service Mesh?

[Just Marvin]

Hi,

Are these [1] instructions expected to work for CRC as well, or are
there different instructions / its not possible to get the istio working on
CRC?

Regards,
Marvin

[1]
https://docs.openshift.com/container-platform/4.1/service_mesh/service_mesh_install/installing-ossm.html
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: [OKD/OCP v4]: deployment on a single node using CodeReady Container

[Just Marvin]

Fernando,

Is CRC only expected to run on bare-metal? I tried running it on a VM
in GCP and it didn't work, complaining about virtualization problems (sorry
- forget the exact error). It runs find on my laptop, but I'd really like
to not muddy up my laptop with all kinds of experimental things.

Regards,
Marvin

On Wed, Sep 18, 2019 at 12:35 PM Fernando Lozano  wrote:

> Hi Joel,
>
> Yes, CRC requires virtualization. It creates and manages a VM, using the
> hypervisor provided by your laptop OS, and runs OpenShift inside that VM.
> AFAIK there is no more all-in-one containerized support for OpenShift so
> more 'oc cluster up' for OpenShift 4.x.
>
> []s, Fernando Lozano
>
>
> On Wed, Sep 18, 2019 at 9:44 AM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>> With CodeReady Container, it's not possible to use it without
>> virtualisation right?  Because it needs CoreOS, and can't startup on an
>> existing docker installation like you can with "oc cluster up"?
>>
>> I'm only asking because I almost got OKD 3.11 running on Windows 10 WSL
>> (windows subsystem for linux) v2.  But if it's a full VM, then running
>> inside WSL 2 doesn't really make sense (and probably doesn't work anyway).
>>
>> On Sat, 14 Sep 2019 at 02:35, Daniel Comnea 
>> wrote:
>>
>>> Recently folks were asking what is the minishift's alternative for v4
>>> and in case you've missed the news see [1]
>>>
>>> Hopefully that will also work for OKD v4 once  the MVP is out.
>>>
>>>
>>> Dani
>>>
>>> [1]
>>> https://developers.redhat.com/blog/2019/09/05/red-hat-openshift-4-on-your-laptop-introducing-red-hat-codeready-containers/
>>> ___
>>> 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
>>
> ___
> 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: configuring access to registry.redhat.io images

[Just Marvin]

Ben, Fernando,

It turns out that saying "no" to the ssh connection prompt causes the
logic to fallback to the normal paths, and then the command works. So many
thanks to getting me to this point. However, the interpretation of the IS
name as a hostname _will_ cause problems for scripts running the command -
so is there a way to turn off that logic?

Regards,
Marvin

On Mon, Sep 16, 2019 at 1:13 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Fernando,
>
> Thanks for offering a solution. I've run into a different problem with
> your syntax (which, if it weren't happening to me, I'd find hilarious):
>
> [zaphod@oc6010654212 ~]$ oc new-app 
> jboss-eap72-openshift:1.0~git@github.<rest
> of enterprise github ssh url> --name=humongous --source-secret= secret>
> The authenticity of host 'jboss-eap72-openshift (23.202.231.166)' can't be
> established.
> ECDSA key fingerprint is
> SHA256:HnzBy7BAfkMCT4uIcdLrpoWiOrnhHhN8k7XMbbB2Epk.
> ECDSA key fingerprint is
> MD5:d1:23:b1:96:eb:66:5f:5f:09:64:b9:27:0e:9e:c5:e4.
> Are you sure you want to continue connecting (yes/no)? no
>
> Turns out that from my machine
>
> zaphod@oc6010654212 ~]$ ping jboss-eap72-openshift
> PING jboss-eap72-openshift (23.202.231.166) 56(84) bytes of data.
> 64 bytes from a23-202-231-166.deploy.static.akamaitechnologies.com
> (23.202.231.166): icmp_seq=1 ttl=53 time=27.7 ms
> ^C
>
> and no, there is nothing in /etc/hosts pointing to this.
>
> How do I turn off the oc command interpreting it as a hostname?
>
> Without the version, and with Ben's suggestion of --loglevel=5, I get
> the following output:
>
> [zaphod@oc6010654212 ~]$ oc new-app
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git
> --name=humongous --source-secret=github-ibm-com-secret --loglevel=5
> I0916 13:09:46.6408332277 newapp.go:644] Docker client did not respond
> to a ping: Get http://unix.sock/_ping: dial unix /var/run/docker.sock:
> connect: no such file or directory
> I0916 13:09:46.6409362277 repository.go:424] Executing git ls-remote
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git
> I0916 13:09:46.9365102277 repository.go:492] Error executing command:
> exit status 128
> I0916 13:09:46.9365872277 repository.go:424] Executing git ls-remote
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git
> I0916 13:09:47.2052352277 repository.go:492] Error executing command:
> exit status 128
> I0916 13:09:47.2053062277 repository.go:424] Executing git ls-remote
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git
> I0916 13:09:48.4936362277 repository.go:492] Error executing command:
> exit status 128
> I0916 13:09:48.4937352277 sourcelookup.go:89] could not list git
> remotes for 
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git:
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> I0916 13:09:48.4937932277 newapp.go:314] treating
> jboss-eap72-openshift~g...@github.ibm.com:kstephe/humongous-stuff.git as a
> component ref
> I0916 13:09:48.4939472277 imagestreamlookup.go:64] checking
> ImageStreams jman/jboss-eap72-openshift with ref "latest"
> I0916 13:09:48.5123292277 imagestreamlookup.go:64] checking
> ImageStreams openshift/jboss-eap72-openshift with ref "latest"
> I0916 13:09:48.5328522277 imagestreamlookup.go:80] unscored
> apicast-gateway: 1
> I0916 13:09:48.5328882277 imagestreamlookup.go:80] unscored
> apicurito-ui: 1
> I0916 13:09:48.5328972277 imagestreamlookup.go:80] unscored cli: 1
> I0916 13:09:48.5329062277 imagestreamlookup.go:80] unscored
> cli-artifacts: 1
> I0916 13:09:48.5329152277 imagestreamlookup.go:80] unscored dotnet: 1
> I0916 13:09:48.5329242277 imagestreamlookup.go:80] unscored
> dotnet-runtime: 1
> I0916 13:09:48.5329322277 imagestreamlookup.go:80] unscored
> eap-cd-openshift: 1
> I0916 13:09:48.5329422277 imagestreamlookup.go:80] unscored
> fis-java-openshift: 1
> I0916 13:09:48.5329522277 imagestreamlookup.go:80] unscored
> fis-karaf-openshift: 1
> I0916 13:09:48.5329612277 imagestreamlookup.go:80] unscored
> fuse-apicurito-generator: 1
> I0916 13:09:48.5329712277 imagestreamlookup.go:80] unscored
> fuse7-console: 1
> I0916 13:09:48.5329792277 imagestreamlookup.go:80] unscored
> fuse7-eap-openshift: 1
> I0916 13:09:48.5329892277 imagestreamlookup.go:80] unscored
> fuse7-java-openshift: 1
> I0916 13:09:48.5329972277 imagestreamlookup.go:80] unscored
> fuse7-karaf-openshift: 1
> 

Re: configuring access to registry.redhat.io images

[Just Marvin]

uot;latest"}
F0916 13:09:48.8197332277 helpers.go:114] error: unable to locate any
images in image streams, local docker images with name
"jboss-eap72-openshift"

The 'oc new-app' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the
'openshift' project
 - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker
engine
  3. Templates in the current project or the 'openshift' project
  4. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to point to an image that does not exist
yet.

See 'oc new-app -h' for examples.
[zaphod@oc6010654212 ~]$

Regards,
Marvin

On Mon, Sep 16, 2019 at 12:59 PM Fernando Lozano  wrote:

> Hi Marvin,
>
> It looks like there is something actually wrong with the standard image
> streams. I have a "hello-word" app on my personal GitHub account. If fails
> with the same error as you if I try to use the EAP image streams with the
> "latest" tag implied:
>
> $ oc new-app jboss-eap72-openshift~https://github.com/flozanorht/war-hello
> --name war
> error: unable to locate any images in image streams, local docker images
> with name "jboss-eap72-openshift"
> ...
>
> But if I use an explicit tag, such as 1.0, I it works just fine:
>
> $ oc get is jboss-eap72-openshift -n openshift
> NAMEIMAGE REPOSITORY
>TAGS UPDATED
> jboss-eap72-openshift
> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift
>   1.0,latest   3 weeks ago
>
> $ oc new-app jboss-eap72-openshift:1.0~
> https://github.com/flozanorht/war-hello --name war
> --> Found image 6189c3b (2 months old) in image stream
> "openshift/jboss-eap72-openshift" under tag "1.0" for
> "jboss-eap72-openshift:1.0"
> ...
>
> It built my app successfully and I was able to access it, after exposing a
> route.
>
>
> []s, Fernando Lozano
>
>
>
> On Mon, Sep 16, 2019 at 1:48 PM Ben Parees  wrote:
>
>> Looks right to me, i'm not sure why new-app is not finding it.
>>
>> Can you try using the --image-stream openshift/jboss-eap72-openshift
>> syntax instead of the ~ syntax and see if it makes a difference?
>>
>> also running with --loglevel=5 might give us more insight about why
>> new-app is not finding your imagestream in the openshift namespace.
>>
>>
>> On Mon, Sep 16, 2019 at 11:53 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Ben, Fernando,
>>>
>>> From the output of "oc get is jboss-eap72-openshift -n openshift -o yaml"
>>>
>>> status:
>>>   dockerImageRepository:
>>> image-registry.openshift-image-registry.svc:5000/openshift/jboss-eap72-openshift
>>>   publicDockerImageRepository:
>>> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift
>>>   tags:
>>>   - items:
>>> - created: "2019-08-23T17:59:24Z"
>>>   dockerImageReference:
>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
>>>   generation: 2
>>>   image:
>>> sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
>>> tag: "1.0"
>>>   - items:
>>> - created: "2019-08-23T17:59:24Z"
>>>   dockerImageReference:
>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235
>>>   generation: 2
>>>   image:
>>> sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235
>>> tag: latest
>>>
>>> Regards,
>>> Marvin
>>>
>>> On Mon, Sep 16, 2019 at 11:20 AM Ben Parees  wrote:
>>>
>>>>
>>>>
>>>> On Mon, Sep 16, 2019 at 11:04 AM Just Marvin <
>>>> marvin.the.cynical.ro...@gmail.com> wrote:
>>>>
>>>>> Fernando,
>>>>>
>>>>>  Thanks for the response, but that syntax is something that I had
>>>>> tried before I posted, but it didn't work.
>>>>>
>>>>> [zaphod@oc6010654212 ~]$ oc new-app 
>>>>> jboss-eap72-openshift~git@github.>>>> ssh url> --name=humongous --source-secret=
>>>>> error: unable to locate any images in image streams, local docker
>>>>>

Re: configuring access to registry.redhat.io images

[Just Marvin]

Ben, Fernando,

>From the output of "oc get is jboss-eap72-openshift -n openshift -o yaml"

status:
  dockerImageRepository:
image-registry.openshift-image-registry.svc:5000/openshift/jboss-eap72-openshift
  publicDockerImageRepository:
default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift
  tags:
  - items:
- created: "2019-08-23T17:59:24Z"
  dockerImageReference:
registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
  generation: 2
  image:
sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
tag: "1.0"
  - items:
- created: "2019-08-23T17:59:24Z"
  dockerImageReference:
registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235
  generation: 2
  image:
sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235
tag: latest

Regards,
Marvin

On Mon, Sep 16, 2019 at 11:20 AM Ben Parees  wrote:

>
>
> On Mon, Sep 16, 2019 at 11:04 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Fernando,
>>
>>  Thanks for the response, but that syntax is something that I had
>> tried before I posted, but it didn't work.
>>
>> [zaphod@oc6010654212 ~]$ oc new-app 
>> jboss-eap72-openshift~git@github.> ssh url> --name=humongous --source-secret=
>> error: unable to locate any images in image streams, local docker images
>> with name "jboss-eap72-openshift"
>>
>> The 'oc new-app' command will match arguments to the following types:
>>
>>   1. Images tagged into image streams in the current project or the
>> 'openshift' project
>>  - if you don't specify a tag, we'll add ':latest'
>>   2. Images in the Docker Hub, on remote registries, or on the local
>> Docker engine
>>   3. Templates in the current project or the 'openshift' project
>>   4. Git repository URLs or local paths that point to Git repositories
>>
>> --allow-missing-images can be used to point to an image that does not
>> exist yet.
>>
>> See 'oc new-app -h' for examples.
>> [zaphod@oc6010654212 ~]$
>>
>> As I showed in my original email, the IS named jboss-eap72-openshift,
>> does exist. So, what am I doing wrong?
>>
>
> can you confirm the imagestream tags imported successfully?
>
> oc get is jboss-eap72-openshift -n openshift -o yaml
>
> if the imports succeeded, you should see something like this in the status
> section:
>
> status:
>   dockerImageRepository:
> image-registry.openshift-image-registry.svc:5000/openshift/jboss-eap72-openshift
>   tags:
>   - items:
> - created: "2019-09-16T13:57:33Z"
>   dockerImageReference:
> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
>   generation: 2
>   image:
> sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7
> tag: "1.0"
>   - items:
> - created: "2019-09-16T13:57:33Z"
>   dockerImageReference:
> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:e78f3020712cf12dc04dfd325e5c4759c298cd1b805f4920a4f41995d469bb0d
>   generation: 2
>   image:
> sha256:e78f3020712cf12dc04dfd325e5c4759c298cd1b805f4920a4f41995d469bb0d
> tag: latest
>
>
>
> if not, you should see an indication of why the import is not succeeding.
>
>
>
>
>>
>> Regards,
>> Marvin
>>
>> On Mon, Sep 16, 2019 at 9:59 AM Fernando Lozano 
>> wrote:
>>
>>> Hi,
>>>
>>> CRC comes ready to use, you do not need to perform any configuration to
>>> use an image stream from the 'openshift' namespace. That namespace already
>>> includes your pull secret (from your Red Hat Developers or customer portal
>>> account) that allows OpenSHift to pull container images from
>>> registry.redhat.io.
>>>
>>> The oc new-app command uses the 'openshift' namespace by default. You
>>> just need to use the image stream name (and tag if you wish) before a tilde
>>> (~) them provide your Git repository URL.
>>>
>>> See the following example, that uses one of the same application from
>>> the DO288 course. It uses the 'php' image stream from the 'openshift'
>>> namespace.
>>>
>>> $ oc new-app php:7.2~https://github.com/RedHatTraining/DO288-apps
>>> --name hello --context-dir php-helloworld
>>>
>>> []s, Fernando Lozano
>>>
>>>
>>>
>>> On Mon, Sep 16, 2019 at 9

Re: configuring access to registry.redhat.io images

[Just Marvin]

Fernando,

 Thanks for the response, but that syntax is something that I had tried
before I posted, but it didn't work.

[zaphod@oc6010654212 ~]$ oc new-app
jboss-eap72-openshift~git@github. --name=humongous --source-secret=
error: unable to locate any images in image streams, local docker images
with name "jboss-eap72-openshift"

The 'oc new-app' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the
'openshift' project
 - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker
engine
  3. Templates in the current project or the 'openshift' project
  4. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to point to an image that does not exist
yet.

See 'oc new-app -h' for examples.
[zaphod@oc6010654212 ~]$

As I showed in my original email, the IS named jboss-eap72-openshift,
does exist. So, what am I doing wrong?

Regards,
Marvin

On Mon, Sep 16, 2019 at 9:59 AM Fernando Lozano  wrote:

> Hi,
>
> CRC comes ready to use, you do not need to perform any configuration to
> use an image stream from the 'openshift' namespace. That namespace already
> includes your pull secret (from your Red Hat Developers or customer portal
> account) that allows OpenSHift to pull container images from
> registry.redhat.io.
>
> The oc new-app command uses the 'openshift' namespace by default. You just
> need to use the image stream name (and tag if you wish) before a tilde (~)
> them provide your Git repository URL.
>
> See the following example, that uses one of the same application from the
> DO288 course. It uses the 'php' image stream from the 'openshift' namespace.
>
> $ oc new-app php:7.2~https://github.com/RedHatTraining/DO288-apps --name
> hello --context-dir php-helloworld
>
> []s, Fernando Lozano
>
>
>
> On Mon, Sep 16, 2019 at 9:17 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm working with code-ready-containers, and I can see that there are
>> image streams that I need in the openshift namespace (for example, the
>> jboss eap 7.2 image). The images themselves are not local - but on
>> registry.redhat.io. My problem is two fold: (1) how do I configure the
>> cluster such that I can simply use these imagestreams from a new-app
>> command (2) How do I set up the cluster so that any needed authentication
>> is pre-defined in the cluster.
>>
>> For (1):
>>
>> zaphod@oc6010654212 ~]$ oc describe is jboss-eap72-openshift -n openshift
>> Name: jboss-eap72-openshift
>> Namespace: openshift
>> Created: 3 weeks ago
>> Labels: samples.operator.openshift.io/managed=true
>> Annotations: openshift.io/display-name=Red Hat JBoss EAP 7.2
>> openshift.io/image.dockerRepositoryCheck=2019-08-23T17:59:24Z
>> openshift.io/provider-display-name=Red Hat, Inc.
>> samples.operator.openshift.io/version=4.1.11
>> version=1.0
>> Image Repository:
>> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift
>> Image Lookup: local=false
>> Unique Images: 2
>> Tags: 2
>>
>> latest
>>   tagged from registry.redhat.io/jboss-eap-7/eap72-openshift:latest
>> prefer registry pullthrough when referencing this tag
>>
>> The problem here is that I can't work out the syntax of the new-app
>> command that can refer to an imagestream in a different namespace
>> (openshift). How does one do this?
>>
>> For (2):
>> I think I need the equivalent of this page, to set things up:
>> https://docs.openshift.com/container-platform/3.11/install_config/configuring_red_hat_registry.html
>>  .
>> However, I can't find the equivalent in the 4.1 docs. I suspect the move to
>> a registry operator means that the procedure is completely different.
>>
>> In addition, I'm trying to use podman. I can login to registry.redhat.io
>> no problem, but I don't know where it stores the token that I'll need to
>> configure auth. Or atleast, I think thats what I need. Not sure.do I
>> actually have to but the userid + password into the cluster?
>>
>> Regards,
>> Marvin
>> ___
>> 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

configuring access to registry.redhat.io images

[Just Marvin]

Hi,

I'm working with code-ready-containers, and I can see that there are
image streams that I need in the openshift namespace (for example, the
jboss eap 7.2 image). The images themselves are not local - but on
registry.redhat.io. My problem is two fold: (1) how do I configure the
cluster such that I can simply use these imagestreams from a new-app
command (2) How do I set up the cluster so that any needed authentication
is pre-defined in the cluster.

For (1):

zaphod@oc6010654212 ~]$ oc describe is jboss-eap72-openshift -n openshift
Name: jboss-eap72-openshift
Namespace: openshift
Created: 3 weeks ago
Labels: samples.operator.openshift.io/managed=true
Annotations: openshift.io/display-name=Red Hat JBoss EAP 7.2
openshift.io/image.dockerRepositoryCheck=2019-08-23T17:59:24Z
openshift.io/provider-display-name=Red Hat, Inc.
samples.operator.openshift.io/version=4.1.11
version=1.0
Image Repository:
default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift
Image Lookup: local=false
Unique Images: 2
Tags: 2

latest
  tagged from registry.redhat.io/jboss-eap-7/eap72-openshift:latest
prefer registry pullthrough when referencing this tag

The problem here is that I can't work out the syntax of the new-app
command that can refer to an imagestream in a different namespace
(openshift). How does one do this?

For (2):
I think I need the equivalent of this page, to set things up:
https://docs.openshift.com/container-platform/3.11/install_config/configuring_red_hat_registry.html
.
However, I can't find the equivalent in the 4.1 docs. I suspect the move to
a registry operator means that the procedure is completely different.

In addition, I'm trying to use podman. I can login to registry.redhat.io no
problem, but I don't know where it stores the token that I'll need to
configure auth. Or atleast, I think thats what I need. Not sure.do I
actually have to but the userid + password into the cluster?

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

Re: install questions (on AWS)

[Just Marvin]

Hi,

I looked at [4], and it isn't clear about which host / hosts the EIPs
will get mapped to. This makes a difference in the cost of my solution. If
I have 10 EIPs and 10 hosts, and I map one per host, the ip addresses are
free. But if OpenShift needs me to map them all to one host, I need to pay
for 9 (because the first one is free). How does this work? To be clear, I'm
asking about v3. I'll ask this and other v4 questions in the forum you
pointed me to.

Thanks,
Marvin

On Wed, Mar 6, 2019 at 3:53 PM W. Trevor King  wrote:

> On Wed, Mar 6, 2019 at 12:38 PM Just Marvin wrote:
> > Firstly - is this the right place to ask questions pertaining to the
> v4 developer preview? If not, would appreciate a pointer to the right place
> please.
>
> [1] suggests [2] for the v4 developer preview.
>
> > I have questions pertaining to how one would install on AWS (v4 or
> v3). AWS charges for Elastic IP's that are not mapped to a running EC2
> instance, or additional elastic IP's (more than one) mapped to a EC2
> instance. I know how many elastic IPs I need for routes, but I'm not sure
> how these IPs need to be assigned. Do I say that all those IP addresses are
> going to be assigned to the host running the SDN (openvswitch?) components?
> Or do I distribute them across the worker nodes? Do I need an elastic ip
> address for kube-dns (and if so, which host is that on - the master)?
>
> The v4 installer [3] will handle all of this for you.  We have
> documentation for user-supplied infrastructure on AWS in the pipe, but
> nothing I can link yet.  Docs for the current EIP allocation are in
> [4].
>
> > If I need to enable https end-user traffic, will I need to install
> CA (but private CA) cert generating components, or does Openshift have the
> capability to dynamically generate the certificates for my routes?
>
> Looks like there is some disccusion of this over in [5].
>
> Cheers,
> Trevor
>
> [1]: https://cloud.openshift.com/clusters/install
> [2]: https://groups.google.com/forum/#!forum/openshift-4-dev-preview
> [3]: https://github.com/openshift/installer/
> [4]:
> https://github.com/openshift/installer/blob/v0.14.0/docs/user/aws/limits.md#elastic-ip-eip
> [5]: https://groups.google.com/d/msg/openshift-4-dev-preview/l3qckiBnhkA
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

install questions (on AWS)

[Just Marvin]

Hi,

Firstly - is this the right place to ask questions pertaining to the v4
developer preview? If not, would appreciate a pointer to the right place
please.

I have questions pertaining to how one would install on AWS (v4 or v3).
AWS charges for Elastic IP's that are not mapped to a running EC2 instance,
or additional elastic IP's (more than one) mapped to a EC2 instance. I know
how many elastic IPs I need for routes, but I'm not sure how these IPs need
to be assigned. Do I say that all those IP addresses are going to be
assigned to the host running the SDN (openvswitch?) components? Or do I
distribute them across the worker nodes? Do I need an elastic ip address
for kube-dns (and if so, which host is that on - the master)?

If I need to enable https end-user traffic, will I need to install CA
(but private CA) cert generating components, or does Openshift have the
capability to dynamically generate the certificates for my routes?

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

Re: Having trouble with "oc explain" syntax

[Just Marvin]

Clayton,

Appreciate the quick response. Is there an alternative for getting
information on the structure of a template? Most of the interesting content
in a template is under that "objects" tree. For example,
template.objects.spec doesn't work either. I tried "oc explain object" but
the tool wasn't too happy about that.

Regards,
Marvin

On Wed, Mar 6, 2019 at 11:53 AM Clayton Coleman  wrote:

> Objects is opaque (literally "any object") so you can't get open api
> metadata on it.
>
> On Wed, Mar 6, 2019 at 11:51 AM Kenneth Stephen <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Hi,
>>
>> The structure of a template is  --> objects -->
>> metadata . "oc explain template.objects" shows me good results, though the
>> output of it doesn't show a metadata child. "oc explain
>> template.objects.metadata" fails saying "error: field "metadata" does not
>> exist". What is the right syntax for dealing with the "objects" array?
>>
>> Thanks,
>> Marvin
>> ___
>> 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