Re: Master node replacement (VMware IPI)

[Clayton Coleman]

> On Nov 21, 2020, at 10:54 AM, Russ Krichevskiy  
> wrote:
>
> I am trying to replace a failed master node that did not reboot
> properly during upgrade (4.6.3 to 4.6.4).
> Referencing documentation here
> https://docs.openshift.com/container-platform/4.6/backup_and_restore/replacing-unhealthy-etcd-member.html#restore-replace-stopped-etcd-member_replacing-unhealthy-etcd-member.
> Deleted etcd member and machine config; brought up a new node and I
> see it rebooted.  I added its new VSphereMachineProviderSpec and it
> shows up as provisioned in openshift-machine-api. However, it will not
> progress any further and will not join.
>
> csr-zfdkh   8h  kubernetes.io/kube-apiserver-client-kubelet
> system:serviceaccount:openshift-machine-config-operator:node-bootstrapper
>  Pending
>
> $ oc adm certificate approve csr-zfdkh
> No resources found
> error: no kind "CertificateSigningRequest" is registered for version
> "certificates.k8s.io/v1" in scheme
> "k8s.io/kubectl/pkg/scheme/scheme.go:28"

What version of oc is this?  Generally this shouldn’t happen unless
something is catastrophically wrong (old client, corrupted local cache
of resources, connected to wrong kube-apiserver, or control plane
broken in ways it cannot be broken anymore).

>
> Any pointers?
>
> ___
> 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: when is a "secrets link" needed?

[Clayton Coleman]

Links were never required by default unless you enabled the "require links
for secrets" option.  That option was dropped between 3.11 and 4.1 and is
currently not supported.

On Thu, Sep 10, 2020 at 2:27 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> 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

Re: when is a "secrets link" needed?

[Clayton Coleman]

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

Re: Ingress Operator Routes and Kubernetes Ingress with TLS

[Clayton Coleman]

You usually have to define a secret for your tls keys

On May 2, 2020, at 9:21 PM, Conrado Poole  wrote:



Hi all,



Trying to figure out if the Ingress Operator is able to create Routes for
Kubernetes objects when they specify a TLS section on their spec.



>From my testing Routes are automatically generated as soon as an Ingress is
created so as long as it does not have the tls: section.



The following Ingress does work and creates 3 Routes



*apiVersion: extensions/v1beta1*

*kind: Ingress*

*metadata:*

*  name: ingress-test*

*spec:*

*rules:*

*  - host: one.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

*  serviceName: one-service*

*  servicePort: 8080*

*  - host: two.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

*  serviceName: two-service*

*  servicePort: 8080*

*  - host: three.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

*  serviceName: three-service*

*  servicePort: 8080*



But this one with TLS (trying to do EDGE termination) does not generate any
routes, the minute I edit the Ingress and remove a host from the TLS
section, the ingress operator creates a route for that one.



*apiVersion: extensions/v1beta1*

*kind: Ingress*

*metadata:*

*  name: ingress-test*

*spec:*

*  tls:*

*  - hosts:*

*- one.apps.mycluster.com *

*secretName: secret-ingress-one*

*  - hosts:*

*- two.apps.mycluster.com *

*secretName: secret-ingress-two*

*  - hosts:*

*- three.apps.mycluster.com *

*secretName: secret-ingress-three*

*  rules:*

*  - host: one.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

*  serviceName: one-service*

*  servicePort: 8080*

*  - host: two.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

* serviceName: two-service*

*  servicePort: 8080*

*  - host: three.apps.mycluster.com *

*http:*

*  paths:*

*  - backend:*

*  serviceName: three-service*

*  servicePort: 8080*



Is there any specific configuration I need to make on the Ingress Operator
to have it generate routes in this case? Or is this working as expected and
it does not support it?



Thanks in advance
___
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: Machine parsing of 'oc adm release mirror'

[Clayton Coleman]

> On Nov 26, 2019, at 12:30 PM, Jon Stanley  wrote:
>
>> On Tue, Nov 26, 2019 at 10:29 AM Clayton Coleman  wrote:
>> The standard kube object
>> is what we would normally output.  You should be able to drop that in
>> the manifests dir the installer creates to obviate the need for the
>> content sources.
>
> Not sure that I follow here - should I use openshift-install create
> manifests and then drop the kube object into the manifests dir (and
> then presumably run openshift-install create ignition-configs) and
> that obviates the need to add anything to install-config.yaml? I
> thought that the use of create manifests was...discouraged :)

Excessively depending on the contents of the manifest dir is “bad”.
Adding your own things there is not.

>
>> Also, in the future there will be other kube objects we output like a
>> configmap containing the payload signature.
>
> OK, this is fine for me and my test clusters, but at $DAYJOB it's
> going to get a bit more complicated to do that. We have a remote
> registry setup to proxy out to quay.io, which we consider untrusted.
> To get images into the internal registry, there's another process that
> we already use for vendor images that we were hoping to leverage for
> this (which includes a security scan). Requiring us to use the oc
> tooling to get that configmap and any other future items would be
> hard. There should be a way to output those objects without doing any
> mirroring as such.

That is what —dry-run will do in 4.3

>
>> Do not hardcode!  :)  We plan to change locations in the future.
>
> You mean to something that doesn't say dev for production images? :)

Where do you think baby production images come from?  :)

>


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

Re: Machine parsing of 'oc adm release mirror'

[Clayton Coleman]

One challenge is that you will need both segments, but only one of
them is a standard kube object (the icsp).  The standard kube object
is what we would normally output.  You should be able to drop that in
the manifests dir the installer creates to obviate the need for the
content sources.

Also, in the future there will be other kube objects we output like a
configmap containing the payload signature.

We definitely need to make this easier to script though

> On Nov 26, 2019, at 8:29 AM, Jon Stanley  wrote:
>
> At the end of an 'oc adm release mirror' instructions are printed as
> to what imageContentSources I need to put in my install-config.yaml.
>
> Would it be a worthwhile enhancement to make an option such that what
> I need to put in is ALL that is returned via stdout? This would make
> it easier to, for example, automate the process of mirroring the
> images (in particular, the nightlies which often change). That said, I
> realize that regardless of the content that's mirrored, that block is
> the same - but if at some future date, a new source gets added, for
> example, that wouldn't be caught if I just hardcoded the
> imageContentSources into my template install-config.yaml.

Do not hardcode!  :)  We plan to change locations in the future.

>
> ___
> 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: Failure to detach Azure Disk in OpenShift 4.2.7 after 15 minutes

[Clayton Coleman]

Did you run must-gather while it couldn’t detach?

Without deeper debug info from the interval it’s hard to say.  If you can
recreate it and run must gather we might be able to find it.

On Nov 24, 2019, at 10:25 PM, Joel Pearson 
wrote:

Hi,

I updated some machine config to configure chrony for masters and workers,
and I found that one of my containers got stuck after the masters had
restarted.

One of the containers still couldn't start for 15 minutes, as the disk was
still attached to master-2 whereas the pod had been scheduled on master-1.

In the end I manually detached the disk in the azure console.

Is this a known issue? Or should I have waited for more than 15 minutes?

Maybe this happened because the masters restarted and maybe whatever is
responsible for detaching the disk got restarted, and there wasn't a
cleanup process to detach from the original node? I'm not sure if this is
further complicated by the fact that my masters are also workers?

Here is the event information from the pod:

  Warning  FailedMount 57s (x8 over 16m)   kubelet,
resource-group-prefix-master-1  Unable to mount volumes for pod
"odoo-3-m9kxs_odoo(c0a31c68-0f2c-11ea-b695-000d3a970043)": timeout expired
waiting for volumes to attach or mount for pod "odoo"/"odoo-3-m9kxs". list
of unmounted volumes=[odoo-data]. list of unattached volumes=[odoo-1
odoo-data default-token-5d6x7]

  Warning  FailedAttachVolume  55s (x15 over 15m)  attachdetach-controller
  AttachVolume.Attach failed for volume
"pvc-61f1ad81-0f24-11ea-8f8f-000d3a970df2" : Attach volume
"resource-group-prefix-dynamic-pvc-61f1ad81-0f24-11ea-8f8f-000d3a970df2" to
instance "resource-group-prefix-master-1" failed with
compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request:
StatusCode=0 -- Original Error: autorest/azure: Service returned an error.
Status= Code="ConflictingUserInput" Message="A disk with name
resource-group-prefix-dynamic-pvc-61f1ad81-0f24-11ea-8f8f-000d3a970df2
already exists in Resource Group RESOURCE-GROUP-PREFIX-RG and is attached
to VM
/subscriptions/-xxx---x/resourceGroups/resource-group-prefix-rg/providers/Microsoft.Compute/virtualMachines/resource-group-prefix-master-2.
'Name' is an optional property for a disk and a unique name will be
generated if not provided."
Target="/subscriptions/-xxx---x/resourceGroups/resource-group-prefix-rg/providers/Microsoft.Compute/disks/resource-group-prefix-dynamic-pvc-61f1ad81-0f24-11ea-8f8f-000d3a970df2"

Thanks,

Joel

___
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: How to recover from failed update in OpenShift 4.2.x?

[Clayton Coleman]

On Nov 17, 2019, at 9:34 PM, Joel Pearson 
wrote:

So, I'm running OpenShift 4.2 on Azure UPI following this blog article:
https://blog.openshift.com/openshift-4-1-upi-environment-deployment-on-microsoft-azure-cloud/
with
a few customisations on the terraform side.

One of the main differences it seems, is how the router/ingress is handled.
Normal Azure uses load balancers, but UPI Azure uses a regular router (that
I'm used to seeing the 3.x version) which is configured by setting the
"HostNetwork"
for the endpoint publishing strategy



This sounds like a bug in Azure UPI.  IPI is the reference architecture, it
shouldn’t have a default divergent from the ref arch.


It was all working fine in OpenShift 4.2.0 and 4.2.2, but when I upgraded
to OpenShift 4.2.4, the router stopped listening on ports 80 and 443, I
could see the pod running with "crictl ps", but a "netstat -tpln" didn't
show anything listening.

I tried updating the version back from 4.2.4 to 4.2.2, but I
accidentally used 4.1.22 image digest value, so I quickly reverted back to
4.2.4 once I saw the apiservers coming up as 4.1.22.  I then noticed that
there was a 4.2.7 release on the candidate-4.2 channel, so I switched to
that, and ingress started working properly again.

So my question is, what is the strategy for recovering from a failed
update? Do I need to have etcd backups and then restore the cluster by
restoring etcd? Ie.
https://docs.openshift.com/container-platform/4.2/backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.html

The upgrade page

specifically says "Reverting your cluster to a previous version, or a
rollback, is not supported. Only upgrading to a newer version is
supported." so is it an expectation for a production cluster that you would
restore from backup if the cluster isn't usable?


Backup, yes.  If you could open a bug for the documentation that would be
great.


Maybe the upgrade page should mention taking backups? Especially if there
is no rollback option.

___
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: access to nightly OCP builds

[Clayton Coleman]

Hrm, the nightly link seems to have disappeared.

The nightly installer binaries are located at:

https://mirror.openshift.com/pub/openshift-v4/clients/ocp-dev-preview/

On Nov 19, 2019, at 7:58 PM, Dale Bewley  wrote:

I'm thwarted from installing OCP 4.2 on OSP 13 due to lack of support for a
typical enterprise TLS config [1]. It is preventing the bootstrap node from
reaching Swift due to "self-signed" cert. I see that may be mostly fixed
upstream [2] now.

If this fix is in a nightly build [3] of OCP 4.3, how do I, as a customer
obtain access for testing? Following the link in the blog post to
try.openshift.com does not seem to offer an answer. RH tech support does
not seem to realize it's a thing or I'm bad at asking questions. Nightlies
of OCP is a thing, right? :)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1735192
[2] https://github.com/openshift/installer/pull/2544
[3]
https://blog.openshift.com/introducing-red-hat-openshift-4-2-in-developer-preview-releasing-nightly-builds/

___
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: How to use extra trusted CA certs when pulling images for a builder

[Clayton Coleman]

Raise a bug to the installler component, yes

On Nov 17, 2019, at 6:03 PM, Joel Pearson 
wrote:

On Mon, 18 Nov 2019 at 12:37, Ben Parees  wrote:

>
>
> On Sun, Nov 17, 2019 at 7:24 PM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>>
>>
>> On Wed, 13 Nov 2019 at 02:43, Ben Parees  wrote:
>>
>>>
>>>
>>> On Mon, Nov 11, 2019 at 11:27 PM Ben Parees  wrote:
>>>


 On Mon, Nov 11, 2019 at 10:47 PM Joel Pearson <
 japear...@agiledigital.com.au> wrote:

>
>
> On Tue, 12 Nov 2019 at 06:56, Ben Parees  wrote:
>
>>
>>
>>>
>>> Can I use the “trustedCA” part of the proxy configuration without
>>> actually specifying an explicit proxy?
>>>
>>
>> you should be able to.  Daneyon can you confirm?  (if you can't i'd
>> consider it a bug).
>>
>> It does work! Thanks for that. user-ca-bundle already existed and had
> my certificate in there, I just needed to reference user-ca-bundle in the
> proxy config.
>

 cool, given that you supplied the CAs during install, and the
 user-ca-bundle CM was created, i'm a little surprised the install didn't
 automatically setup the reference in the proxyconfig resource for you.  I'm
 guessing it did not because there was no actual proxy hostname configured.
 I think that's a gap we should close..would you mind filing a bug?  (
 bugzilla.redhat.com).  You can submit it against the install component.

>>>
>>> fyi I've filed a bug for this aspect of the issues you ran into:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1771564
>>>
>>>
>> Thanks for raising this, reading through the related github tickets it
>> looks like I've opened a can of worms to some degree.
>>
>
> Yes there's some difference of opinion on what the out of box desired
> behavior is, but at a minimum you've exposed a gap in our documentation
> that we will get fixed.
>
>
> I also just discovered that the openshift cluster version operator (CVO),
isn't quite configured correctly out of the box to use the correct trusted
CA certs (which means it can't download cluster updates).

It correctly mounts /etc/ssl/certs from the host (the masters), but it
fails to also mount /etc/pki, because the certs are a symlink
/etc/ssl/certs/ca-bundle.crt ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

I couldn't find where the installer sets up the CVO but an example of what
is missing is here.
https://github.com/openshift/cluster-version-operator/blob/01a7825179246fa708ac64de96e6675c0bf9a930/bootstrap/bootstrap-pod.yaml#L44-L46


Is there an existing bug for this? Or should I raise a bugzilla for this?
Would it be part of the installer?

___
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: How to use extra trusted CA certs when pulling images for a builder

[Clayton Coleman]

On Nov 12, 2019, at 3:44 AM, Joel Pearson 
wrote:



On Tue, 12 Nov 2019 at 15:37, Ben Parees  wrote:

>
>
> On Mon, Nov 11, 2019 at 11:26 PM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>> I've now discovered that the cluster-samples-operator doesn't seem honour
>> the proxy settings, and I see lots of errors in the
>> cluster-samples-operator- pod logs
>>
>> time="2019-11-12T04:15:49Z" level=warning msg="Image import for
>> imagestream dotnet tag 2.1 generation 2 failed with detailed message
>> Internal error occurred: Get https://I /v2/
>> : x509: certificate signed by unknown
>> authority"
>>
>> Is there a way to get that operator to use the same user-ca-bundle?
>>
>
> image import should be using those CAs (it's really about the
> openshift-apiserver, not the samples operator) automatically (sounds like
> another potential bug, but i'll let Oleg weigh in on this one).
>
> However barring that, you can use the mechanism described here to
> setup additional CAs for importing from registries:
>
> https://docs.openshift.com/container-platform/4.2/openshift_images/image-configuration.html#images-configuration-file_image-configuration
>
> you can follow the more detailed instructions here:
>
> https://docs.openshift.com/container-platform/4.2/builds/setting-up-trusted-ca.html#configmap-adding-ca_setting-up-trusted-ca
>

I tried this approach but it didn't work for me.

I ran this command:

oc create configmap registry-cas -n openshift-config \
--from-file=registry.redhat.io..5000=/path/to/ca.crt \
--from-file=registry.redhat.io..443=/path/to/ca.crt \
--from-file=registry.redhat.io=/path/to/ca.crt

and:

oc patch image.config.openshift.io/cluster --patch
'{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge

And that still didn't work. First I deleted the
cluster-samples-operator- pod, then I tried forcing the masters to
restart by touching some machine config (I don't know a better way).
But it still didn't work.  Maybe the samples operator doesn't let you
easily override the trusted CA certs?


No, as Ben said this should be working.  Please file a bug.



>
>
> (Brandi/Adam, we should really include the example from that second link,
> in the general "image resource configuration" page from the first link).
>
> Unfortunately it does not allow you to reuse the user-ca-bundle CM since
> the format of the CM is a bit different (needs an entry per registry
> hostname).
>
> ___
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: Failing to bootstrap disconnected 4.2 cluster on metal

[Clayton Coleman]

There is a known bug in 4.2 where image stream content from the
release payload is not mirrored correctly.  That is slated to be
fixed.

> On Oct 28, 2019, at 8:39 PM, W. Trevor King  wrote:
>
>> On Mon, Oct 28, 2019 at 5:08 PM Joel Pearson wrote:
>> It looks like image streams don't honor the imageContentSources mirror, and 
>> try to reach out to the internet.
>
> Mirrors only apply to by-digest pullspecs.  You may need to patch your
> image specs to use the mirrors [1] explicitly if you want them.
>
> Cheers,
> Trevor
>
> [1]: 
> https://github.com/openshift/release/blob/592c29c2b0f5422201e0cb2dce5e3f6bb7654cce/ci-operator/templates/openshift/installer/cluster-launch-installer-e2e.yaml#L222-L263
>
> ___
> 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: Failing to bootstrap disconnected 4.2 cluster on metal

[Clayton Coleman]

On Oct 28, 2019, at 8:07 PM, Joel Pearson 
wrote:

> Maybe must-gather could be included in the release manifest so that it's
> available in disconnected environments by default?
> It is:
>   $ oc adm release info --image-for=must-gather
> quay.io/openshift-release-dev/ocp-release:4.2.0
>
> quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:34ff29512304f77b0ab70ea6850e7f8295a4d19e497ab690ea5102a7044ea993
> If your 'oc adm must-gather' is reaching out to Quay, instead of
> hitting your mirror, it may be because your samples operator has yet
> to get the mirrored must-gather ImageStream set up.


It looks like image streams don't honor the imageContentSources mirror, and
try to reach out to the internet.

I had a look at the openshift/must-gather image stream and there was an
error saying:

Internal error occurred: Get https://quay.io/v2: dial tcp: lookup quay.io
on 172.30.0.10:53 server misbehaving

Running "oc adm must-gather --image
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:34ff29512304f77b0ab70ea6850e7f8295a4d19e497ab690ea5102a7044ea993"
actually worked.

That (un)available typo should be fixed in master by [1], but looks
> like that hasn't been backported to 4.2.z.  But look for the
> machine-config daemon that is unready (possibly by listing Pods), and
> see why it's not going ready.


Turns out that all of the machine-config daemon's are ready (I can see 7 of
them all marked as ready). But the machine-config operator just doesn't
appear to be trying anymore.

It's listed as Available=False Progressing=False and Degraded=True.

I tried deleting the operator pod in the hope that it'd kickstart
something, but it didn't seem to help.

I noticed a message right up the top saying:
event.go:247] Could not construct reference to: '' Will not
report event 'Normal' 'LeaderElection' 'machine-config-operator-5f47...
become leader'

The pod that I deleted had that same message too, is this a red herring?

I have must-gather logs now, except that it will probably be complicated to
get them off this air-gapped system.  Are there any pointers about where I
should look to find out why it's no longer progressing? Can I make the
operator try again somehow?

I also noticed that the dns operator is marked available, but there is a
degraded status saying that "Not all desired DNS DaemonSets available"
however, they are all available.


Almost always means a node is broken / blocked / unable to schedule pods,
which prevents DNS from deploying.


On Tue, 29 Oct 2019 at 05:24, W. Trevor King  wrote:

> On Mon, Oct 28, 2019 at 4:05 AM Joel Pearson wrote:
> > Maybe must-gather could be included in the release manifest so that it's
> available in disconnected environments by default?
>
> It is:
>
>   $ oc adm release info --image-for=must-gather
> quay.io/openshift-release-dev/ocp-release:4.2.0
>
> quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:34ff29512304f77b0ab70ea6850e7f8295a4d19e497ab690ea5102a7044ea993
>
> If your 'oc adm must-gather' is reaching out to Quay, instead of
> hitting your mirror, it may be because your samples operator has yet
> to get the mirrored must-gather ImageStream set up.
>
> >> Failed to resync 4.2.0 because: timed out waiting for the condition
> during waitForFaemonsetRollout: Daemonset machine-config-daemon is not
> ready. status (desired:7, updated 7, ready: 6, unavailable: 6)
>
> That (un)available typo should be fixed in master by [1], but looks
> like that hasn't been backported to 4.2.z.  But look for the
> machine-config daemon that is unready (possibly by listing Pods), and
> see why it's not going ready.
>
> Cheers,
> Trevor
>
> [1]:
> https://github.com/openshift/machine-config-operator/commit/efb6a96a5bcb13cb3c0c0a0ac0c2e7b022b72665
>


-- 
Kind Regards,

Joel Pearson
Agile Digital | Senior Software Consultant

Love Your Software™ | ABN 98 106 361 273
p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au

___
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: Failing to bootstrap disconnected 4.2 cluster on metal

[Clayton Coleman]

Yes, that is a known 4.2 bug.

> On Oct 28, 2019, at 2:24 PM, W. Trevor King  wrote:
>
>> On Mon, Oct 28, 2019 at 4:05 AM Joel Pearson wrote:
>> Maybe must-gather could be included in the release manifest so that it's 
>> available in disconnected environments by default?
>
> It is:
>
>  $ oc adm release info --image-for=must-gather
> quay.io/openshift-release-dev/ocp-release:4.2.0
>  
> quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:34ff29512304f77b0ab70ea6850e7f8295a4d19e497ab690ea5102a7044ea993
>
> If your 'oc adm must-gather' is reaching out to Quay, instead of
> hitting your mirror, it may be because your samples operator has yet
> to get the mirrored must-gather ImageStream set up.
>
>>> Failed to resync 4.2.0 because: timed out waiting for the condition during 
>>> waitForFaemonsetRollout: Daemonset machine-config-daemon is not ready. 
>>> status (desired:7, updated 7, ready: 6, unavailable: 6)
>
> That (un)available typo should be fixed in master by [1], but looks
> like that hasn't been backported to 4.2.z.  But look for the
> machine-config daemon that is unready (possibly by listing Pods), and
> see why it's not going ready.
>
> Cheers,
> Trevor
>
> [1]: 
> https://github.com/openshift/machine-config-operator/commit/efb6a96a5bcb13cb3c0c0a0ac0c2e7b022b72665
>
> ___
> 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: Failing to bootstrap disconnected 4.2 cluster on metal

[Clayton Coleman]

We probably need to remove the example from the docs and highlight
that you must copy the value reported by image mirror

> On Oct 27, 2019, at 11:33 AM, W. Trevor King  wrote:
>
>> On Sun, Oct 27, 2019 at 2:17 AM Joel Pearson wrote:
>> Ooh, does this mean 4.2.2 is out or the release is imminent? Should I be 
>> trying to install 4.2.2 instead of 4.2.0?
>
> 4.2.2 exists and is in candidate-4.2.  That means it's currently
> unsupported.  The point of candidate-* testing is to test the releases
> to turn up anything that should block them going stable, so we're
> certainly launching a bunch of throw-away 4.2.2 clusters at this
> point, and other folks are welcome to do that too.  But if you want
> stability and support, you should wait until it is promoted into
> fast-4.2 or stable-4.2 (which may never happen if testing turns up a
> serious-enough issue).  So "maybe" to both your question ;).
>
>> I mirrored quay.io/openshift-release-dev/ocp-release:4.2.0
>
> Yeah, should be no CI-registry images under that.
>
> Cheers,
> Trevor
>
> ___
> 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: router stats

[Clayton Coleman]

Metrics are exposed via the controller process in the pod (pid1), not the
HAProxy process.

On Mon, Oct 14, 2019 at 1:27 PM Tim Dudgeon  wrote:

> I'm trying to see the router stats as described here:
> https://docs.okd.io/3.11/admin_guide/router.html
>
> I can see this from within the container using the command:
>
> echo 'show stat' | socat - UNIX-CONNECT:/var/lib/haproxy/run/haproxy.sock
>
> But they do not seem to be being exposed through the web listener as
> described in that doc. In fact I can't see anything in the
> haproxy.config file that suggests that haproxy is exposing stats on port
> 1936 or any other port.
>
> The installation was a fairly standard openshift-ansible install so I'm
> sure the defaults have not been changed.
>
> Are there any instructions for how to get this working?
>
> Thanks
> Tim
>
> ___
> 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: Cannot retrieve ignition config from machine-config-server - expired certs

[Clayton Coleman]

We should supper a longer before window - there’s really no cost to us
because we require ntp after cluster startup and our rotation window
is days, not hours.

> On Oct 1, 2019, at 7:35 PM, W. Trevor King  wrote:
>
>> On Tue, Oct 1, 2019 at 4:24 PM Jon Stanley wrote:
>> I fixed the hostname problem, reinstalled, and now I'm right back here :(
>
> Give it a day or so and see if you fall back into the window where the
> node's clock lines up with the cert's validity window?  Or is the new
> cluster stuck on something else?
>
> Cheers,
> Trevor
>
> ___
> 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: Any tool to convert DeploymentConfig to Deployment

[Clayton Coleman]

Note: Triggers and image streams also work on deployments.

Are you looking to change these objects live, or in config files on disk?

> On Aug 27, 2019, at 6:42 AM, Cameron Braid  wrote:
>
> I have a bunch of DeploymentConfig resources I need to convert to Deployment 
> resources.
>
> Does anyone know of a tool to do this conversion?
>
> I realise that there are some features that aren't convertable (triggers, 
> image streams etc..) but I don't need these features
>
> Cameron
> ___
> 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: Follow up on OKD 4

[Clayton Coleman]

> On Jul 25, 2019, at 2:32 PM, Fox, Kevin M  wrote:
>
> While "just works" is a great goal, and its relatively easy to accomplish in 
> the nice, virtualized world of vm's, I've found it is often not the case in 
> the dirty realm of real physical hardware. Sometimes you must rebuild/replace 
> a kernel or add a kernel module to get things to actually work. If you don't 
> support that, Its going to be a problem for many a site.

Ok, so this would be the “I want to be able to run my own kernel” use case.

That’s definitely something I would expect to be available with OKD in
the existing proposal, you would just be providing a different ostree
image at install time.

How often does this happen with fedora today?  I don’t hear it brought
up often so I may just be oblivious to something folks deal with more.
Certainly fcos should work everywhere existing fedora works, but if a
substantial set of people want that flexibility it’s a great data
point.

>
> Thanks,
> Kevin
> 
> From: dev-boun...@lists.openshift.redhat.com 
> [dev-boun...@lists.openshift.redhat.com] on behalf of Josh Berkus 
> [jber...@redhat.com]
> Sent: Thursday, July 25, 2019 11:23 AM
> To: Clayton Coleman; Aleksandar Lazic
> Cc: users; dev
> Subject: Re: Follow up on OKD 4
>
>> On 7/25/19 6:51 AM, Clayton Coleman wrote:
>> 1. Openshift 4 isn’t flexible in the ways people want (Ie you want to
>> add an rpm to the OS to get a kernel module, or you want to ship a
>> complex set of config and managing things with mcd looks too hard)
>> 2. You want to build and maintain these things yourself, so the “just
>> works” mindset doesn’t appeal.
>
> FWIW, 2.5 years ago when we were exploring having a specific
> Atomic+Openshift distro for Kubernetes, we did a straw poll of Fedora
> Cloud users.  We found that 2/3 of respondees wanted a complete package
> (that is, OKD+Atomic) that installed and "just worked" out of the box,
> and far fewer folks wanted to hack their own.  We never had such a
> release due to insufficient engineering resources (and getting stuck
> behind the complete rewrite of the Fedora build pipelines), but that was
> the original goal.
>
> Things may have changed in the interim, but I think that a broad user
> survey would still find a strong audience for a "just works" distro in
> Fedora.
>
> --
> --
> Josh Berkus
> Kubernetes Community
> Red Hat OSAS
>
> ___
> dev mailing list
> d...@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

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

Re: Follow up on OKD 4

[Clayton Coleman]

On Thu, Jul 25, 2019 at 11:58 AM Fox, Kevin M  wrote:

> Yeah, There is the question what it is now, and the question what it
> potentially should be. I'm asking more from a where should it go standpoint.
>
> Right now, k8s distro's are very much in the early linux distro days.
> Here's how to get a base os going. Ok, now your on your own to deploy
> anything on it. Download tarball, build it, install it, write init script,
> etc. If you look a the total package list in the modern linux distro, the
> os level stuff is usually a very small percentage of the software in the
> distro.
>
> These days we've moved on so far from "the distro is a kernel" that folks
> even talk about running a redhat, a fedora, or a centos container. Thats
> really #4 level stuff only.
>
> olm is like yum. a tool to install stuff. So kind of a #3 tool. Its the
> software packaging itself, mysql, apache, etc. that is also part of the
> distro that is mostly missing I think. a container is like an rpm. one way
> to define a linux distro is a collection of prebuilt/tested/supported rpms
> for common software.
>
> In the linux os today, you can start from "I want to deploy a mysql
> server" and I trust redhat to provide good software, so you go and yum
> install mysql. I could imagine similarly OKD as a collection of software to
> deploy on top of a k8s, where there is an optional, self hosting OS part
> (1-3) the same way Fedora/Centos can be used purely #4 with containers, or
> as a full blown os+workloads.
>
> Sure, you can let the community build all their own stuff. Thats possible
> in linux distro's today too and shouldn't be blocked. But it misses the
> point why folks deploy software from linux distro's over getting it from
> the source. I prefer to run mysql from redhat as apposed to upstream
> because of all the extras the distro packagers provide.
>
> Not trying to short change all the hard work in getting a k8s going. okd's
> doing an amazing job at that. That's really important too. But so is all
> the distro work around software packaging, and thats still much more in its
> infancy I think. We're still mostly at the point where we're debating if
> thats the end users problem.
>
> The package management tools are coming around nicely, but not so much yet
> the distro packages. How do we get a k8s distro of this form going? Is that
> in the general scope of OKD, or should there be a whole new project just
> for that?
>

Honestly we've been thinking of the core components as just that - CVO,
MCO, release images, integrated OS with updates.  That's the core compose
(the minimum set of components you need for maintainable stuff).  I think
Mike's comment about MCO supporting multiple OS's is something like that,
and CVO + release tooling is that too.  I think from the perspective of the
project as a whole I had been thinking that "OKD is both the tools and
process for k8s-as-distro".  OLM is a small component of that, like yum.
CVO + installer + bootstrap is anaconda.  The machine-os and k8s are like
systemd.

That's why I'm asking about how much flexibility people want - after all,
Fedora doesn't let you choose which glibc you use.  If people want to
compose the open source projects differently, all the projects are there
today and should be easy to fork, and we could also consider how we make
them easier to fork in the future.

The discuss OKD4 started with was "what kind of distro do people want".  If
there's a group who want to get more involved in the "build a distro" part
of tools that exist, that definitely seems like a different use case.


>
> The redhat container catalog is a good start too, but we need to be
> thinking all the way up to the k8s level.
>
> Should it be "okd k8s distro" or "fedora k8s distro" or something else?
>
> Thanks,
> Kevin
>
> --
> *From:* Clayton Coleman [ccole...@redhat.com]
> *Sent:* Wednesday, July 24, 2019 10:31 AM
> *To:* Fox, Kevin M
> *Cc:* Michael Gugino; users; dev
> *Subject:* Re: Follow up on OKD 4
>
>
>
> On Wed, Jul 24, 2019 at 12:45 PM Fox, Kevin M  wrote:
>
>> Ah, this raises an interesting discussion I've been wanting to have for a
>> while.
>>
>> There are potentially lots of things you could call a distro.
>>
>> Most linux distro's are made up of several layers:
>> 1. boot loader - components to get the kernel running
>> 2. kernel - provides a place to run higher level software
>> 3. os level services - singletons needed to really call the os an os.
>> (dhcp, systemd, dbus, etc)
>> 4. prebuilt/tested, generic software/services - workload (mysql, apache,
>> firefox, gnome, etc)
>>
>> For sake of discussio

Re: Follow up on OKD 4

[Clayton Coleman]

> On Jul 25, 2019, at 4:19 AM, Aleksandar Lazic 
>  wrote:
>
> HI.
>
>> Am 25.07.2019 um 06:52 schrieb Michael Gugino:
>> I think FCoS could be a mutable detail.  To start with, support for
>> plain-old-fedora would be helpful to make the platform more portable,
>> particularly the MCO and machine-api.  If I had to state a goal, it
>> would be "Bring OKD to the largest possible range of linux distros to
>> become the defacto implementation of kubernetes."
>
> I agree here with Michael. As FCoS or in general CoS looks technical a good 
> idea
> but it limits the flexibility of possible solutions.
>
> For example when you need to change some system settings then you will need to
> create a new OS Image, this is not very usable in some environments.

I think something we haven’t emphasized enough is that openshift 4 is
very heavily structured around changing the cost and mental model
around this.  The goal was and is to make these sorts of things
unnecessary.  Changing machine settings by building golden images is
already the “wrong” (expensive and error prone) pattern - instead, it
should be easy to reconfigure machines or to launch new containers to
run software on those machines.  There may be two factors here at
work:

1. Openshift 4 isn’t flexible in the ways people want (Ie you want to
add an rpm to the OS to get a kernel module, or you want to ship a
complex set of config and managing things with mcd looks too hard)
2. You want to build and maintain these things yourself, so the “just
works” mindset doesn’t appeal.

The initial doc alluded to the DIY / bucket of parts use case (I can
assemble this on my own but slightly differently) - maybe we can go
further now and describe the goal / use case as:

I want to be able to compose my own Kubernetes distribution, and I’m
willing to give up continuous automatic updates to gain flexibility in
picking my own software

Does that sound like it captures your request?

Note that a key reason why the OS is integrated is so that we can keep
machines up to date and do rolling control plane upgrades with no
risk.  If you take the OS out of the equation the risk goes up
substantially, but if you’re willing to give that up then yes, you
could build an OKD that doesn’t tie to the OS.  This trade off is an
important one for folks to discuss.  I’d been assuming that people
*want* the automatic and safe upgrades, but maybe that’s a bad
assumption.

What would you be willing to give up?

>
> It would be nice to have the good old option to use the ansible installer to
> install OKD/Openshift on other Linux distribution where ansible is able to 
> run.
>
>> Also, it would be helpful (as previously stated) to build communities
>> around some of our components that might not have a place in the
>> official kubernetes, but are valuable downstream components
>> nevertheless.
>>
>> Anyway, I'm just throwing some ideas out there, I wouldn't consider my
>> statements as advocating strongly in any direction.  Surely FCoS is
>> the natural fit, but I think considering other distros merits
>> discussion.
>
> +1
>
> Regards
> Aleks
>
>
>>> On Wed, Jul 24, 2019 at 9:23 PM Clayton Coleman  wrote:
>>>
>>>> On Jul 24, 2019, at 9:14 PM, Michael Gugino  wrote:
>>>>
>>>> I think what I'm looking for is more 'modular' rather than DIY.  CVO
>>>> would need to be adapted to separate container payload from host
>>>> software (or use something else), and maintaining cross-distro
>>>> machine-configs might prove tedious, but for the most part, rest of
>>>> everything from the k8s bins up, should be more or less the same.
>>>>
>>>> MCD is good software, but there's not really much going on there that
>>>> can't be ported to any other OS.  MCD downloads a payload, extracts
>>>> files, rebases ostree, reboots host.  You can do all of those steps
>>>> except 'rebases ostree' on any distro.  And instead of 'rebases
>>>> ostree', we could pull down a container that acts as a local repo that
>>>> contains all the bits you need to upgrade your host across releases.
>>>> Users could do things to break this workflow, but it should otherwise
>>>> work if they aren't fiddling with the hosts.  The MCD payload happens
>>>> to embed an ignition payload, but it doesn't actually run ignition,
>>>> just utilizes the file format.
>>>>
>>>> From my viewpoint, there's nothing particularly special about ignition
>>>> in our current process either.  I had the entire OCP 4 stack running
>>>> on RHEL using the same exact ignition payload, a minimal amount of
>>>&g

Re: Follow up on OKD 4

[Clayton Coleman]

> On Jul 24, 2019, at 9:14 PM, Michael Gugino  wrote:
>
> I think what I'm looking for is more 'modular' rather than DIY.  CVO
> would need to be adapted to separate container payload from host
> software (or use something else), and maintaining cross-distro
> machine-configs might prove tedious, but for the most part, rest of
> everything from the k8s bins up, should be more or less the same.
>
> MCD is good software, but there's not really much going on there that
> can't be ported to any other OS.  MCD downloads a payload, extracts
> files, rebases ostree, reboots host.  You can do all of those steps
> except 'rebases ostree' on any distro.  And instead of 'rebases
> ostree', we could pull down a container that acts as a local repo that
> contains all the bits you need to upgrade your host across releases.
> Users could do things to break this workflow, but it should otherwise
> work if they aren't fiddling with the hosts.  The MCD payload happens
> to embed an ignition payload, but it doesn't actually run ignition,
> just utilizes the file format.
>
> From my viewpoint, there's nothing particularly special about ignition
> in our current process either.  I had the entire OCP 4 stack running
> on RHEL using the same exact ignition payload, a minimal amount of
> ansible (which could have been replaced by cloud-init userdata), and a
> small python library to parse the ignition files.  I was also building
> repo containers for 3.10 and 3.11 for Fedora.  Not to say the
> OpenShift 4 experience isn't great, because it is.  RHEL CoreOS + OCP
> 4 came together quite nicely.
>
> I'm all for 'not managing machines' but I'm not sure it has to look
> exactly like OCP.  Seems the OCP installer and CVO could be
> adapted/replaced with something else, MCD adapted, pretty much
> everything else works the same.

Sure - why?  As in, what do you want to do?  What distro do you want
to use instead of fcos?  What goals / outcomes do you want out of the
ability to do whatever?  Ie the previous suggestion (the auto updating
kube distro) has the concrete goal of “don’t worry about security /
updates / nodes and still be able to run containers”, and fcos is a
detail, even if it’s an important one.  How would you pitch the
alternative?


>
>> On Wed, Jul 24, 2019 at 12:05 PM Clayton Coleman  wrote:
>>
>>
>>
>>
>>> On Wed, Jul 24, 2019 at 10:40 AM Michael Gugino  wrote:
>>>
>>> I tried FCoS prior to the release by using the assembler on github.
>>> Too much secret sauce in how to actually construct an image.  I
>>> thought atomic was much more polished, not really sure what the
>>> value-add of ignition is in this usecase.  Just give me a way to build
>>> simple image pipelines and I don't need ignition.  To that end, there
>>> should be an okd 'spin' of FCoS IMO.  Atomic was dead simple to build
>>> ostree repos for.  I'd prefer to have ignition be opt-in.  Since we're
>>> supporting the mcd-once-from to parse ignition on RHEL, we don't need
>>> ignition to actually install okd.  To me, it seems FCoS was created
>>> just to have a more open version of RHEL CoreOS, and I'm not sure FCoS
>>> actually solves anyone's needs relative to atomic.  It feels like we
>>> jumped the shark on this one.
>>
>>
>> That’s feedback that’s probably something you should share in the fcos 
>> forums as well.  I will say that I find the OCP + RHEL experience 
>> unsatisfying and doesn't truly live up to what RHCOS+OCP can do (since it 
>> lacks the key features like ignition and immutable hosts).  Are you saying 
>> you'd prefer to have more of a "DIY kube bistro" than the "highly 
>> opinionated, totally integrated OKD" proposal?  I think that's a good 
>> question the community should get a chance to weigh in on (in my original 
>> email that was the implicit question - do you want something that looks like 
>> OCP4, or something that is completely different).
>>
>>>
>>>
>>> I'd like to see OKD be distro-independent.  Obviously Fedora should be
>>> our primary target (I'd argue Fedora over FCoS), but I think it should
>>> be true upstream software in the sense that apache2 http server is
>>> upstream and not distro specific.  To this end, perhaps it makes sense
>>> to consume k/k instead of openshift/origin for okd.  OKD should be
>>> free to do wild and crazy things independently of the enterprise
>>> product.  Perhaps there's a usecase for treating k/k vs
>>> openshift/origin as a swappable base layer.
>>
>>
>> That’s even more dramatic a change from OKD even as it was in 3.x.  I’d be 
>> 

Re: Follow up on OKD 4

[Clayton Coleman]

On Wed, Jul 24, 2019 at 12:45 PM Fox, Kevin M  wrote:

> Ah, this raises an interesting discussion I've been wanting to have for a
> while.
>
> There are potentially lots of things you could call a distro.
>
> Most linux distro's are made up of several layers:
> 1. boot loader - components to get the kernel running
> 2. kernel - provides a place to run higher level software
> 3. os level services - singletons needed to really call the os an os.
> (dhcp, systemd, dbus, etc)
> 4. prebuilt/tested, generic software/services - workload (mysql, apache,
> firefox, gnome, etc)
>
> For sake of discussion, lets map these layers a bit, and assume that the
> openshift specific components can be added to a vanilla kubernetes. We then
> have
>
> 1. linux distro (could be k8s specific and micro)
> 2. kubernetes control plane & kubelets
> 3. openshift components (auth, ingress, cicd/etc)
> 4. ?  (operators + containers, helm + containers, etc)
>
> openshift use to be defined as being 1-3.
>

> As things like ake/eks/gke make it easy to deploy 1-2, maybe openshift
> should really become modular so it focuses more on 3 and 4.
>

That's interesting that you'd say that.  I think kube today is like
"install a kernel with bash and serial port magic", whereas OpenShift 4 is
"here's a compose, an installer, a disk formatter, yum, yum repos,
lifecycle, glibc, optional packages, and sys utils".  I don't know if you
can extend the analogy there (if you want to use EKS, you're effectively
running on someone's VPS, but you can only use their distro and you can't
change anything), but definitely a good debate.


>
> As for having something that provides a #1 that is super tiny/easy to
> maintain so that you can do #2 on top easily, I'm for that as well, but
> should be decoupled from 3-4 I think. Should you be able to switch out your
> #1 for someone elses #1 while keeping the rest? That's the question from
> previous in the thread.
>

I think the analogy I've been using is that openshift is a proper distro in
the sense that you don't take someone's random kernel and use it with
someone else's random glibc and a third party's random gcc, but you might
not care about the stuff on top.  The things in 3 for kube feel more like
glibc than "which version of Firefox do I install", since a cluster without
ingress isn't very useful.


>
> #4 I think is very important and while the operator framework is starting
> to make some inroads on it, there is still a lot of work to do to make an
> equivalent of the 'redhat' distro of software that runs on k8s.
>
> A lot of focus has been on making a distro out of k8s. but its really
> mostly been at the level of, how do I get a kernel booted/upgraded. I think
> the more important distro thing #4 is how do you make a distribution of
> prebuilt, easy to install software to run on top of k8s. Redhat's distro is
> really 99% userspace and a bit of getting the thing booted.
>

Really?  I don't think that's true at all - I'd flip it around and say it's
85% booted, with 15% user space today.  I'd probably draw the line at auth,
ingress, and olm as being "the top of the bottom".   OpenShift 4 is 100%
about making that bottom layer just working, rather than being about OLM up.


> Its value is in having a suite of prebuilt, tested, stable, and easily
> installable/upgradable software  with a team of humans that can provide
> support for it. The kernel/bootloader part is really just a means to enable
> #4. No one installs a kernel/os just to get a kernel. This part is
> currently lacking. Where is the equivalent of Redhat/Centos/Fedora for #4.
>
> In the context of OKD, which of these layers is OKD focused on?
>

In the proposal before it was definitely 1-3 (which is the same as the OCP4
path).  If you only care about 4, you're talking more about OLM on top of
Kube, which is more like JBoss or something like homebrew on Mac (you don't
upgrade your Mac via home-brew, but you do consume lots of stuff out there).


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

Re: Follow up on OKD 4

[Clayton Coleman]

On Wed, Jul 24, 2019 at 12:18 PM Fox, Kevin M  wrote:

> So, last I heard OpenShift was starting to modularize, so it could load
> the OpenShift parts as extensions to the kube-apiserver? Has this been
> completed? Maybe the idea below of being able to deploy vanilla k8s is
> workable as the OpenShift parts could easily be added on top?
>

OpenShift in 3.x was a core control plane plus 3-5 components.  In 4.x it's
a kube control plane, a bunch of core wiring, the OS, the installer, and
then a good 30 other components.  OpenShift 4 is so far beyond "vanilla
kube + extensions" now that while it's probably technically possible to do
that, it's less of "openshift" and more of "a kube cluster with a few
APIs".  I.e. openshift is machine management, automated updates, integrated
monitoring, etc.


>
> Thanks,
> Kevin
> 
> From: dev-boun...@lists.openshift.redhat.com [
> dev-boun...@lists.openshift.redhat.com] on behalf of Michael Gugino [
> mgug...@redhat.com]
> Sent: Wednesday, July 24, 2019 7:40 AM
> To: Clayton Coleman
> Cc: users; dev
> Subject: Re: Follow up on OKD 4
>
> I tried FCoS prior to the release by using the assembler on github.
> Too much secret sauce in how to actually construct an image.  I
> thought atomic was much more polished, not really sure what the
> value-add of ignition is in this usecase.  Just give me a way to build
> simple image pipelines and I don't need ignition.  To that end, there
> should be an okd 'spin' of FCoS IMO.  Atomic was dead simple to build
> ostree repos for.  I'd prefer to have ignition be opt-in.  Since we're
> supporting the mcd-once-from to parse ignition on RHEL, we don't need
> ignition to actually install okd.  To me, it seems FCoS was created
> just to have a more open version of RHEL CoreOS, and I'm not sure FCoS
> actually solves anyone's needs relative to atomic.  It feels like we
> jumped the shark on this one.
>
> I'd like to see OKD be distro-independent.  Obviously Fedora should be
> our primary target (I'd argue Fedora over FCoS), but I think it should
> be true upstream software in the sense that apache2 http server is
> upstream and not distro specific.  To this end, perhaps it makes sense
> to consume k/k instead of openshift/origin for okd.  OKD should be
> free to do wild and crazy things independently of the enterprise
> product.  Perhaps there's a usecase for treating k/k vs
> openshift/origin as a swappable base layer.
>
> It would be nice to have a more native kubernetes place to develop our
> components against so we can upstream them, or otherwise just build a
> solid community around how we think kubernetes should be deployed and
> consumed.  Similar to how Fedora has a package repository, we should
> have a Kubernetes component repository (I realize operatorhub fulfulls
> some of this, but I'm talking about a place for OLM and things like
> MCD to live).
>
> I think we could integrate with existing package managers via a
> 'repo-in-a-container' type strategy for those not using ostree.
>
> As far as slack vs IRC, I vote IRC or any free software solution (but
> my preference is IRC because it's simple and I like it).
>
> On Sun, Jul 21, 2019 at 12:28 PM Clayton Coleman 
> wrote:
> >
> >
> >
> > On Sat, Jul 20, 2019 at 12:40 PM Justin Cook  wrote:
> >>
> >> Once upon a time Freenode #openshift-dev was vibrant with loads of
> activity and publicly available logs. I jumped in asked questions and Red
> Hatters came from the woodwork and some amazing work was done.
> >>
> >> Perfect.
> >>
> >> Slack not so much. Since Monday there have been three comments with two
> reply threads. All this with 524 people. Crickets.
> >>
> >> Please explain how this is better. I’d really love to know why IRC
> ceased. It worked and worked brilliantly.
> >
> >
> > Is your concern about volume or location (irc vs slack)?
> >
> > Re volume: It should be relatively easy to move some common discussion
> types into the #openshift-dev slack channel (especially triage / general
> QA) that might be distributed to other various slack channels today (both
> private and public), and I can take the follow up to look into that.  Some
> of the volume that was previously in IRC moved to these slack channels, but
> they're not anything private (just convenient).
> >
> > Re location:  I don't know how many people want to go back to IRC from
> slack, but that's a fairly easy survey to do here if someone can volunteer
> to drive that, and I can run the same one internally.  Some of it is
> inertia - people have to be in slack sig-* channels - and some of it is
> preferen

Re: Follow up on OKD 4

[Clayton Coleman]

On Wed, Jul 24, 2019 at 10:40 AM Michael Gugino  wrote:

> I tried FCoS prior to the release by using the assembler on github.
> Too much secret sauce in how to actually construct an image.  I
> thought atomic was much more polished, not really sure what the
> value-add of ignition is in this usecase.  Just give me a way to build
> simple image pipelines and I don't need ignition.  To that end, there
> should be an okd 'spin' of FCoS IMO.  Atomic was dead simple to build
> ostree repos for.  I'd prefer to have ignition be opt-in.  Since we're
> supporting the mcd-once-from to parse ignition on RHEL, we don't need
> ignition to actually install okd.  To me, it seems FCoS was created
> just to have a more open version of RHEL CoreOS, and I'm not sure FCoS
> actually solves anyone's needs relative to atomic.  It feels like we
> jumped the shark on this one.
>

That’s feedback that’s probably something you should share in the fcos
forums as well.  I will say that I find the OCP + RHEL experience
unsatisfying and doesn't truly live up to what RHCOS+OCP can do (since it
lacks the key features like ignition and immutable hosts).  Are you saying
you'd prefer to have more of a "DIY kube bistro" than the "highly
opinionated, totally integrated OKD" proposal?  I think that's a good
question the community should get a chance to weigh in on (in my original
email that was the implicit question - do you want something that looks
like OCP4, or something that is completely different).


>
> I'd like to see OKD be distro-independent.  Obviously Fedora should be
> our primary target (I'd argue Fedora over FCoS), but I think it should
> be true upstream software in the sense that apache2 http server is
> upstream and not distro specific.  To this end, perhaps it makes sense
> to consume k/k instead of openshift/origin for okd.  OKD should be
> free to do wild and crazy things independently of the enterprise
> product.  Perhaps there's a usecase for treating k/k vs
> openshift/origin as a swappable base layer.
>

That’s even more dramatic a change from OKD even as it was in 3.x.  I’d be
happy to see people excited about reusing cvo / mcd and be able to mix and
match, but most of the things here would be a huge investment to build.  In
my original email I might call this the “I want to build my own distro" -
if that's what people want to build, I think we can do things to enable
it.  But it would probably not be "openshift" in the same way.


>
> It would be nice to have a more native kubernetes place to develop our
> components against so we can upstream them, or otherwise just build a
> solid community around how we think kubernetes should be deployed and
> consumed.  Similar to how Fedora has a package repository, we should
> have a Kubernetes component repository (I realize operatorhub fulfulls
> some of this, but I'm talking about a place for OLM and things like
> MCD to live).
>

MCD is really tied to the OS.  The idea of a generic MCD seems like it
loses the value of MCD being specific to an OS.

I do think there are two types of components we have - things designed to
work well with kube, and things designed to work well with "openshift the
distro".  The former can be developed against Kube (like operator hub /
olm) but the latter doesn't really make sense to develop against unless it
matches what is being built.  In that vein, OKD4 looking not like OCP4
wouldn't benefit you or the components.


>
> I think we could integrate with existing package managers via a
> 'repo-in-a-container' type strategy for those not using ostree.
>

A big part of openshift 4 is "we're tired of managing machines".  It sounds
like you are arguing for "let people do whatever", which is definitely
valid (but doesn't sound like openshift 4).


>
> As far as slack vs IRC, I vote IRC or any free software solution (but
> my preference is IRC because it's simple and I like it).
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Follow up on OKD 4

[Clayton Coleman]

On Sat, Jul 20, 2019 at 12:40 PM Justin Cook  wrote:

> Once upon a time Freenode #openshift-dev was vibrant with loads of
> activity and publicly available logs. I jumped in asked questions and Red
> Hatters came from the woodwork and some amazing work was done.
>
> Perfect.
>
> Slack not so much. Since Monday there have been three comments with two
> reply threads. All this with 524 people. Crickets.
>
> Please explain how this is better. I’d really love to know why IRC ceased.
> It worked and worked brilliantly.
>

Is your concern about volume or location (irc vs slack)?

Re volume: It should be relatively easy to move some common discussion
types into the #openshift-dev slack channel (especially triage / general
QA) that might be distributed to other various slack channels today (both
private and public), and I can take the follow up to look into that.  Some
of the volume that was previously in IRC moved to these slack channels, but
they're not anything private (just convenient).

Re location:  I don't know how many people want to go back to IRC from
slack, but that's a fairly easy survey to do here if someone can volunteer
to drive that, and I can run the same one internally.  Some of it is
inertia - people have to be in slack sig-* channels - and some of it is
preference (in that IRC is an inferior experience for long running
communication).


>
> There are mentions of sigs and bits and pieces, but absolutely no
> progress. I fail to see why anyone would want to regress. OCP4 maybe
> brilliant, but as I said in a private email, without upstream there is no
> culture or insurance we’ve come to love from decades of heart and soul.
>
> Ladies and gentlemen, this is essentially getting to the point the
> community is being abandoned. Man years of work acknowledged with the
> roadmap pulled out from under us.
>

I don't think that's a fair characterization, but I understand why you feel
that way and we are working to get the 4.x work moving.  The FCoS team as
mentioned just released their first preview last week, I've been working
with Diane and others to identify who on the team is going to take point on
the design work, and there's a draft in flight that I saw yesterday.  Every
component of OKD4 *besides* the FCoS integration is public and has been
public for months.

I do want to make sure we can get a basic preview up as quickly as possible
- one option I was working on with the legal side was whether we could
offer a short term preview of OKD4 based on top of RHCoS.  That is possible
if folks are willing to accept the terms on try.openshift.com in order to
access it in the very short term (and then once FCoS is available that
would not be necessary).  If that's an option you or anyone on this thread
are interested in please let me know, just as something we can do to speed
up.


>
> I completely understand the disruption caused by the acquisition. But,
> after kicking the tyres and our meeting a few weeks back, it’s been pretty
> quiet. The clock is ticking on corporate long-term strategies. Some of
> those corporates spent plenty of dosh on licensing OCP and hiring
> consultants to implement.
>

> Red Hat need to lead from the front. Get IRC revived, throw us a bone, and
> have us put our money where our mouth is — we’ll get involved. We’re
> begging for it.
>
> Until then we’re running out of patience via clientele and will need to
> start a community effort perhaps by forking OKD3 and integrating upstream.
> I am not interested in doing that. We shouldn’t have to.
>

In the spirit of full transparency, FCoS integrated into OKD is going to
take several months to get to the point where it meets the quality bar I'd
expect for OKD4.  If that timeframe doesn't work for folks, we can
definitely consider other options like having RHCoS availability behind a
terms agreement, a franken-OKD without host integration (which might take
just as long to get and not really be a step forward for folks vs 3), or
other, more dramatic options.  Have folks given FCoS a try this week?
https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/.
That's a great place to get started

As always PRs and fixes to 3.x will continue to be welcomed and that effort
continues unabated.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Follow up on OKD 4

[Clayton Coleman]

The kube #openshift-dev slack might also make sense, since we have 518
people there right now

On Fri, Jul 19, 2019 at 12:46 PM Christian Glombek 
wrote:

> Hi everyone,
>
> first of all, I'd like to thank Clayton for kicking this off!
>
> As I only just joined this ML, let me quickly introduce myself:
>
> I am an Associate Software Engineer on the OpenShift
> machine-config-operator (mco) team and I'm based out of Berlin, Germany.
> Last year, I participated in Google Summer of Code as a student with
> Fedora IoT and joined Red Hat shortly thereafter to work on the Fedora
> CoreOS (FCOS) team.
> I joined the MCO team when it was established earlier this year.
>
> Having been a Fedora/Atomic community member for some years, I'm a strong
> proponent of using FCOS as base OS for OKD and would like to see it enabled
> :)
> As I work on the team that looks after the MCO, which is one of the parts
> of OpenShift that will need some adaptation in order to support another
> base OS, I am confident I can help with contributions there
> (of course I don't want to shut the door for other OSes to be used as base
> if people are interested in that :).
>
> Proposal: Create WG and hold regular meetings
>
> I'd like to propose the creation of the OKD Working Group that will hold
> bi-weekly meetings.
> (or should we call it a SIG? Also open to suggestions to find the right
> venue: IRC?, OpenShift Commons Slack?).
>
> I'll survey some people in the coming days to find a suitable meeting time.
>
> If you have any feedback or suggestions, please feel free to reach out,
> either via this list or personally!
> I can be found as lorbus on IRC/Fedora, @lorbus42 on Twitter, or simply
> via email :)
>
> I'll send out more info here ASAP. Stay tuned!
>
> With kind regards
>
> CHRISTIAN GLOMBEK
> Associate Software Engineer
>
> Red Hat GmbH, registred seat: Grassbrunn
> Commercial register: Amtsgericht Muenchen, HRB 153243
> Managing directors: Charles Cachera, Michael O'Neill, Thomas Savage, Eric 
> Shander
>
>
>
> On Wed, Jul 17, 2019 at 10:45 PM Clayton Coleman 
> wrote:
>
>> Thanks for everyone who provided feedback over the last few weeks.
>> There's been a lot of good feedback, including some things I'll try to
>> capture here:
>>
>> * More structured working groups would be good
>> * Better public roadmap
>> * Concrete schedule for OKD 4
>> * Concrete proposal for OKD 4
>>
>> I've heard generally positive comments about the suggestions and
>> philosophy in the last email, with a desire for more details around what
>> the actual steps might look like, so I think it's safe to say that the idea
>> of "continuously up to date Kubernetes distribution" resonated.  We'll
>> continue to take feedback along this direction (private or public).
>>
>> Since 4 was the kickoff for this discussion, and with the recent release
>> of the Fedora CoreOS beta (
>> https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/) figuring
>> prominently in the discussions so far, I got some volunteers from that team
>> to take point on setting up a working group (SIG?) around the initial level
>> of integration and drafting a proposal.
>>
>> Steve and Christian have both been working on Fedora CoreOS and
>> graciously agreed to help drive the next steps on Fedora CoreOS and OKD
>> potential integration into a proposal.  There's a rough level draft doc
>> they plan to share - but for now I will turn this over to them and they'll
>> help organize time / forum / process for kicking off this effort.  As that
>> continues, we'll identify new SIGs to spawn off as necessary to cover other
>> topics, including initial CI and release automation to deliver any
>> necessary changes.
>>
>> Thanks to everyone who gave feedback, and stay tuned here for more!
>>
> ___
> 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

Follow up on OKD 4

[Clayton Coleman]

Thanks for everyone who provided feedback over the last few weeks.  There's
been a lot of good feedback, including some things I'll try to capture here:

* More structured working groups would be good
* Better public roadmap
* Concrete schedule for OKD 4
* Concrete proposal for OKD 4

I've heard generally positive comments about the suggestions and philosophy
in the last email, with a desire for more details around what the actual
steps might look like, so I think it's safe to say that the idea of
"continuously up to date Kubernetes distribution" resonated.  We'll
continue to take feedback along this direction (private or public).

Since 4 was the kickoff for this discussion, and with the recent release of
the Fedora CoreOS beta (
https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/) figuring
prominently in the discussions so far, I got some volunteers from that team
to take point on setting up a working group (SIG?) around the initial level
of integration and drafting a proposal.

Steve and Christian have both been working on Fedora CoreOS and graciously
agreed to help drive the next steps on Fedora CoreOS and OKD potential
integration into a proposal.  There's a rough level draft doc they plan to
share - but for now I will turn this over to them and they'll help organize
time / forum / process for kicking off this effort.  As that continues,
we'll identify new SIGs to spawn off as necessary to cover other topics,
including initial CI and release automation to deliver any necessary
changes.

Thanks to everyone who gave feedback, and stay tuned here for more!
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

OKD 4 - A Modest Proposal

[Clayton Coleman]

tps://commons.openshift.org/events.html#event%7Cokd4-road-map-release-update-with-clayton-coleman-red-hat%7C960>
to further explore these topics with the wider community. I hope you’ll
join the conversation and look forward to hearing from the others across
the community.  Meeting details here: http://bit.ly/OKD4ReleaseUpdate

Thank you for your continued support and for being a part of the OKD
community,

Clayton Coleman

Kubernetes and OKD contributor
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: OKD 4.x

[Clayton Coleman]

The cluster bootstrap process uses ignition to ensure masters join the
cluster, and there are a number of aspects of how upgrades of control plane
nodes work that assume the ability to use ostree to update and pivot the
nodes during boot to the correct content set.

I’m sure it’s possible to get a cluster working without a coreos-style OS
(ignition, pivot, ostree), but it would lack the ability to update itself,
so it wouldn’t really be a coherent whole.  The work in fcos is probably
the place to start (we still have to spec out the details, which is on me)
just because it works together with the cluster rather than being distinct.

On Jun 6, 2019, at 6:00 AM, Thode Jocelyn < .th...@elca.ch> wrote:

Hi Clayton,



Will there still be support for Centos 8 witjout the CoreOS spin ? Or will
OKD/Openshift 4 only work with a CoreOS based system ?



Cheers

Jocelyn Thode



*From:* dev-boun...@lists.openshift.redhat.com <
dev-boun...@lists.openshift.redhat.com> *On Behalf Of *Clayton Coleman
*Sent:* jeudi, 6 juin 2019 12:15
*To:* Alix ander 
*Cc:* OpenShift Users List ;
d...@lists.openshift.redhat.com
*Subject:* Re: OKD 4.x



We’re currently working on how Fedora CoreOS will integrate into OKD.
There’s a fair chunk of work that needs to be done and FCoS has a broader
mission than RHCoS does, so its a bit further behind (since OpenShift 4 /
OKD 4 require an OS with ignition and ostree).  Stay tuned, I was going to
write out a work plan for this and share it here.  There’s no current plan
for a centos version, since there’s a lot of interest in FCoS for a newer
kernel.



Until that happens, try.openshift.com makes it easy to get an evaluation of
OCP4 for test and development even if you don’t have a subscription.






On Jun 6, 2019, at 6:04 AM, Alix ander  wrote:

hey guys,



> OKD is upstream code base upon which Red Hat OpenShift Online and Red Hat
OpenShift Container Platform are built



[red hat openshift 4 is now available](
https://blog.openshift.com/red-hat-openshift-4-is-now-available/)



Does any body know if  there is any plan for OKD 4.x ? I am unable to find
any information regarding OKD especially for bare metal.

Here
<https://docs.openshift.com/container-platform/4.1/installing/installing_bare_metal/installing-bare-metal.html>is
a documentation for installing the container-platform on bare-metal which
uses Red Hat Enterprise Linux CoreOS(RHCOS) which presuppose red hat
subscription. RHCOS will not be possible though to use on OKD - Is there
something like CentOS for CoreOS ?



Cheers,
Alix

___
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: OKD 4.x

[Clayton Coleman]

We’re currently working on how Fedora CoreOS will integrate into OKD.
There’s a fair chunk of work that needs to be done and FCoS has a broader
mission than RHCoS does, so its a bit further behind (since OpenShift 4 /
OKD 4 require an OS with ignition and ostree).  Stay tuned, I was going to
write out a work plan for this and share it here.  There’s no current plan
for a centos version, since there’s a lot of interest in FCoS for a newer
kernel.

Until that happens, try.openshift.com makes it easy to get an evaluation of
OCP4 for test and development even if you don’t have a subscription.



On Jun 6, 2019, at 6:04 AM, Alix ander  wrote:

hey guys,


> OKD is upstream code base upon which Red Hat OpenShift Online and Red Hat
OpenShift Container Platform are built


[red hat openshift 4 is now available](
https://blog.openshift.com/red-hat-openshift-4-is-now-available/)


Does any body know if  there is any plan for OKD 4.x ? I am unable to find
any information regarding OKD especially for bare metal.

Here
is
a documentation for installing the container-platform on bare-metal which
uses Red Hat Enterprise Linux CoreOS(RHCOS) which presuppose red hat
subscription. RHCOS will not be possible though to use on OKD - Is there
something like CentOS for CoreOS ?



Cheers,
Alix

___
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: OCP Image Signing

[Clayton Coleman]

skopeo is available via Homebrew on the Mac - if there’s a gap in function
for signing it’s very reasonable to file an issue to ensure it works
properly.

On May 3, 2019, at 7:32 PM, Clayton Coleman  wrote:



On May 3, 2019, at 4:59 PM, Grace Thompson  wrote:


We'd like to implement image signing for our imagestreams. We are unable to
use `atomic cli` or skopeo to sign the images since we support other OS's
and not just rpm based distros.


If you would clarify - what part of “rpm based distros” impacts signing for
you?


There seems to be a way to write signatures using the registry API as
written here:

https://docs.openshift.com/container-platform/3.9/admin_guide/image_signatures.html#accessing-image-signatures-using-registry-api


My question is about the signature.json payload. How is this file
generated? Do we still need to sign the images first using `atomic cli` or
skopeo? Is there a more generic way of signing the image streams?


What are you trying to sign?

An atomic container signature is a detached signature identifying an image
by its digest (which is a cryptographically strong verification of
particular contents of that image).

Signing an image stream rarely makes sense, unless you are trying to prove
that a particular set of tags were applied to a particular set of digests.
Knowing more about your use case will help answer your question.


{

"version": 2,

"type": "atomic",

"name":
"sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23
",

"content": ""

}


___
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: OCP Image Signing

[Clayton Coleman]

On May 3, 2019, at 4:59 PM, Grace Thompson  wrote:


We'd like to implement image signing for our imagestreams. We are unable to
use `atomic cli` or skopeo to sign the images since we support other OS's
and not just rpm based distros.


If you would clarify - what part of “rpm based distros” impacts signing for
you?


There seems to be a way to write signatures using the registry API as
written here:

https://docs.openshift.com/container-platform/3.9/admin_guide/image_signatures.html#accessing-image-signatures-using-registry-api


My question is about the signature.json payload. How is this file
generated? Do we still need to sign the images first using `atomic cli` or
skopeo? Is there a more generic way of signing the image streams?


What are you trying to sign?

An atomic container signature is a detached signature identifying an image
by its digest (which is a cryptographically strong verification of
particular contents of that image).

Signing an image stream rarely makes sense, unless you are trying to prove
that a particular set of tags were applied to a particular set of digests.
Knowing more about your use case will help answer your question.


{

"version": 2,

"type": "atomic",

"name":
"sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23
",

"content": ""

}


___
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: internal registry vs external use

[Clayton Coleman]

It really depends on your use case.  The development team uses the
integrated registry to serve content for other clusters.  We also use
quay.io and docker hub to host mirrors of that content.

On Thu, May 2, 2019 at 4:12 AM Harald Dunkel 
wrote:

> HI folks,
>
> I understand that I can expose the internal registry for external
> use, but is this wise? Wouldn't it be better to not interfere with
> okd's registry management and to use a dedicated external registry
> for images created *outside* of okd?
>
> What is best practice here?
>
>
> Every helpful comment is highly appreciated
> Harri
>
> ___
> 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: Having trouble with "oc explain" syntax

[Clayton Coleman]

A template is a list of "any object".  So the things you put as items in
the objects array are the things you would "oc explain
deployment|service|secret|*" on

On Wed, Mar 6, 2019 at 12:16 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> 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

Re: Having trouble with "oc explain" syntax

[Clayton Coleman]

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

Re: Origin 3.6 cluster no longer deploying deployemnts

[Clayton Coleman]

Are there errors in the controller logs?

On Dec 2, 2018, at 2:42 AM, Cameron Braid  wrote:

Sorry, a typo - its a 3.7 cluster not 3.6

 ~> oc version

oc v3.7.2+282e43f

kubernetes v1.7.6+a08f5eeb62

features: Basic-Auth


Server

openshift v3.7.0+7ed6862

kubernetes v1.7.6+a08f5eeb62

On Sun, 2 Dec 2018 at 18:39 Cameron Braid  wrote:

> I have a strange issue in my 3.6 cluster.  I create a extensions/v1beta1 
> Deployment
> and nothing happens.  No pods are created.  oc describe shows
>
>  oc -n drivenow-staging-x describe deployment strimzi-cluster-operator
> Name: strimzi-cluster-operator
> Namespace: drivenow-staging-x
> CreationTimestamp: Sun, 02 Dec 2018 01:33:10 +1100
> Labels: app=strimzi
> Annotations: 
> Selector: name=strimzi-cluster-operator
> *Replicas: 1 desired | 0 updated | 0 total | 0 available | 0 unavailable*
> StrategyType: Recreate
> MinReadySeconds: 0
> Pod Template:
>   Labels: name=strimzi-cluster-operator
>   Service Account: strimzi-cluster-operator
>   Containers:
>strimzi-cluster-operator:
> Image: strimzi/cluster-operator:0.6.0
> Port: 
> Limits:
>   cpu: 1
>   memory: 256Mi
> Requests:
>   cpu: 200m
>   memory: 256Mi
> Liveness: http-get http://:8080/healthy delay=10s timeout=1s
> period=30s #success=1 #failure=3
> Readiness: http-get http://:8080/ready delay=10s timeout=1s
> period=30s #success=1 #failure=3
> Environment: ...
> Mounts: 
>   Volumes: 
> OldReplicaSets: 
> NewReplicaSet: 
> Events: 
>
> All nodes are ready, schedulable and there doesnt appear to be antyhing in
> the logs.
>
> I've tried restarting origin-node, origin-master-api and
> origin-master-controllers on all nodes and that has no impact.
>
> I'm out of ideas.
>
> Cameron
>
___
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: OKD 3.10 restartPolicy into DC

[Clayton Coleman]

Deployment Configs do not allow batch behavior, but they do allow “test”
behavior that allows you to trigger a scale up when a change happens, and
if everything succeeds you’ll get a “passing” deployment.  When success or
failure happens it is scaled down to zero.  This can be used to validate
that things deploy correctly.

But if you are doing actual batch workloads, jobs would be more appropriate.

On Nov 12, 2018, at 9:01 AM, François VILLAIN 
wrote:

Hi,



Maybe you should create a Job object instead of a DC object.

https://docs.openshift.com/container-platform/3.10/dev_guide/jobs.html



François



*De :* users-boun...@lists.openshift.redhat.com <
users-boun...@lists.openshift.redhat.com> *De la part de* Marcello Lorenzi
*Envoyé :* lundi 12 novembre 2018 14:56
*À :* users 
*Objet :* OKD 3.10 restartPolicy into DC



Hi All,

we're trying to configure a DC with a pod executed in a batch mode. This
pod completes its job and we would not restart it if the exit code is 0.

We tried to configure the restartPolicy on DC configuration to Never but
the master-api doesn't permit this change.



Is it possible to configure this behavior on DC?



Thanks a lot,

Marcello

___
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: OKD v3.11.0 has been tagged and pushed to GitHub

[Clayton Coleman]

Right now, a fresh install is required.  The master and installer teams are
sorting through what an upgrade would look like.  I'm sure there will be an
upgrade at some point, but it might not be ready when the 4.0 bits are
available.  Stay tuned.

On Fri, Oct 12, 2018 at 4:37 AM David Conde  wrote:

> On the 4.0 changes, is the plan to provide the ability to upgrade from
> 3.11 to 4.0 or would a totally fresh install be required?
>
> On Thu, Oct 11, 2018 at 4:55 PM Clayton Coleman 
> wrote:
>
>> https://github.com/openshift/origin/releases/tag/v3.11.0 contains the
>> release notes and latest binaries.
>>
>> The v3.11.0 tag on docker.io is up to date and will be a rolling tag
>> (new fixes will be delivered there).
>>
>> Thanks to everyone on their hard work!
>> ___
>> 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

OKD v3.11.0 has been tagged and pushed to GitHub

[Clayton Coleman]

https://github.com/openshift/origin/releases/tag/v3.11.0 contains the
release notes and latest binaries.

The v3.11.0 tag on docker.io is up to date and will be a rolling tag (new
fixes will be delivered there).

Thanks to everyone on their hard work!
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: openshift origin all in one

[Clayton Coleman]

The all-in-one path David is referring to (openshift start) is not used by
minishift (which uses of cluster up).

There will be a replacement path for the core functionality of running a
single master in a VM, we’re still working out the details.  The end goal
would be for an equivalent easy to use flow on a single machine that is
more aligned with the new installer, but we aren’t there yet.

On Oct 1, 2018, at 9:31 AM, Fernando Lozano  wrote:

Without all-in-one, how will minishift work? I assume we still want an easy
to use option for developers.

On Mon, Oct 1, 2018 at 10:12 AM subscription sites <
subscription.si...@gmail.com> wrote:

> Hi David,
>
>
> so there will not be a possibility anymore to install on one host? Also no
> alternative for the use-cases that all-in-one covers today, such as
> experiment with openshift?
> Basically, the "oc cluster up" command disappears?
>
> Also: is this kind of decisions available somewhere online, like a public
> roadmap for the product?
>
> Kr,
>
> Peter
>
> On Mon, Oct 1, 2018 at 2:08 PM David Eads  wrote:
>
>> In the release after 3.11, the all-in-one will no longer be available and
>> because it isn't considered a production installation, we have no plans to
>> provide a clean migration from an all-in-one configuration.
>>
>> On Sun, Sep 30, 2018 at 3:56 PM Aleksandar Kostadinov <
>> akost...@redhat.com> wrote:
>>
>>> Here my personal thoughts and experience. Not some sort of official
>>> advice.
>>>
>>> subscription sites wrote on 09/29/18 18:40:
>>> > Hello,
>>> >
>>> >
>>> > I'm wondering with regard to the all-in-one setup:
>>> > - I know the documentation doesn't say it's considered production, but
>>> > what would the downside be of using this on a VPS to host production
>>> > apps? Except for the lack of redundancy obviously, the host goes down
>>> > and it's all down, but my alternative would be to not use openshift
>>> and
>>> > use plain docker on one host, so availability isn't my premium
>>> concern.
>>> > Is it not recommended from a security perspective, considering how
>>> it's
>>> > setup using "oc cluster up", or are there other concerns for not using
>>> > it in production?
>>>
>>> Except for missing on HA and running some non-app resources (console,
>>> node, controllers, etcd, router, etc.), then I see no other drawbacks.
>>>
>>> > - When setting up an all-in-one on an internet-exposed host, how can
>>> you
>>> > best protect the web console? Isn't it a bit "light" security wise to
>>> > just depend on username/password for protection? Is there a
>>> possibility
>>> > to use multifactor or certificate based authentication? I also tried
>>>
>>> Depends on how you choose and manage your password. For more options you
>>> can try to use keycloak auth provider. This should allow you to setup
>>> 2-factor auth IIRC.
>>>
>>> > blocking the port with iptables and using ssh with port forwarding,
>>> but
>>> > this doesn't seem to work, both if I set the public-master option to
>>> the
>>> > public ip or localhost?
>>>
>>> How does it fail when you set to localhost?
>>>
>>> I assume using some sort of VPN can also help but I don't see why `ssh`
>>> shouldn't work. An alternative would be to use `ssh -D` to proxy your
>>> traffic through the remote host and setup your browser to use that socks
>>> server when accessing console. But still think normal port forwarding
>>> should do the job.
>>>
>>> >
>>> >
>>> > Thanks for any help you can provide!
>>> >
>>> >
>>> > Regards,
>>> >
>>> >
>>> >
>>> > Peter
>>> >
>>> >
>>> > ___
>>> > 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
>
___
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: deleting docker images on nodes

[Clayton Coleman]

OpenShift automatically prunes images off nodes and has done so since at
least 3.4.  Please see
https://docs.okd.io/latest/admin_guide/garbage_collection.html

On Tue, Sep 25, 2018 at 12:32 PM Tim Dudgeon  wrote:

> As time progresses more and more docker images will be present on the
> nodes in a cluster as different pods get deployed.
> This could use up significant disk space.
>
> Does openshift provide a mechanism for pruning these, or is doing this
> up to the cluster administrator?
>
> ___
> 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: Atomic Host support on OpenShift 3.11 and up

[Clayton Coleman]

On Sep 25, 2018, at 6:22 AM, Joel Pearson 
wrote:

Clayton, does this mean that in OpenShift 4.0 you'd be able to take a
vanilla kubernetes installation and then install a bunch of OpenShift
operators and basically have an OpenShift cluster?


It’s not really the goal, since there are still admission plugins and
patches in Kube-* binaries that are necessary to keep backward
compatibility and round our multitenant security.  Also, the top level
operator will manage the control plane, which won’t work well if you don’t
have a control plane or someone else installed it.  Finally, node
management will be a fully integrated part of 4.0, so many of the
advantages of Red Hat CoreOS would be lost.

That said, if you squint, yes, and we will certainly be doing things that
make the separation clearer over time.

Or is that not really the goal of migration to operators? Is it just to
make future OpenShift releases easier to package?


The goal is a fully managed update process that works at the click of a
button, full node management on all cloud providers and metal, better and
more dynamic cluster config (moving config to api objects you can kubectl
apply post-install), and better future support for extending openshift with
other ecosystem projects like istio and knative


On Fri, Sep 7, 2018 at 9:18 AM Clayton Coleman  wrote:

> Master right now will be labeled 4.0 when 3.11 branches (happening right
> now).  It’s possible we might later cut a 3.12 but no plans at the current
> time.
>
> Changes to master will include significant changes as the core is rewired
> with operators - you’ll also see much more focus on preparing
> openshift/installer and refractors in openshift-ansible that reduce its
> scope as the hand-off to operators happens.  Expect churn for the next
> months.
>
> On Sep 6, 2018, at 6:23 PM, Daniel Comnea  wrote:
>
> Clayton,
>
> 4.0 is that going to be 3.12 rebranded (if we follow the current release
> cycle) or 3.13 ?
>
>
>
> On Thu, Sep 6, 2018 at 2:34 PM Clayton Coleman 
> wrote:
>
>> The successor to atomic host will be RH CoreOS and the community
>> variants.  That is slated for 4.0.
>>
>> > On Sep 6, 2018, at 9:25 AM, Marc Ledent  wrote:
>> >
>> > Hi all,
>> >
>> > I have read in the 3.10 release notes that Atomic Host is deprecated
>> and will nod be supported starting release 3.11.
>> >
>> > What this means? Is it advisable to migrate all Atomic host vms to
>> "standard" RHEL server?
>> >
>> > Kind regards,
>> > Marc
>> >
>> >
>> > ___
>> > 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: How to make 172.30.0.1 (kubernetes service) health checked?

[Clayton Coleman]

Masters should actually remove themselves, but maybe that regressed.  I’ll
try to take a look but removing themselves when they receive a sigterm is a
good idea.

On Sep 10, 2018, at 6:58 PM, Joel Pearson 
wrote:

Hi Clayton,

Sorry for the extensive delay, but I’ve been thinking about this more and
I’m wondering if it’s safe to remove a master from the endpoint just before
restarting it (say in Ansible), so that failures aren’t seen inside the
cluster?

Or would something in Kubernetes just go and add the master back to the
endpoint?

Alternatively, would it be possible to tell Kubernetes not to add the
individual masters to that endpoint and use a load balancer instead? Say a
private ELB for example?

Or are there future features in kubernetes that will make master failover
more reliable internally?

Thanks,

Joel
On Thu, 28 Jun 2018 at 12:48 pm, Clayton Coleman 
wrote:

> In OpenShift 3.9, when a master goes down the endpoints object should be
> updated within 15s (the TTL on the record for the master).  You can check
> the value of "oc get endpoints -n default kubernetes" - if you still see
> the master IP in that list after 15s then something else is wrong.
>
> On Wed, Jun 27, 2018 at 9:33 AM, Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>> Hi,
>>
>> I'm running OpenShift 3.9 on AWS with masters in HA mode using Classic
>> ELB's doing TCP load balancing.  If I restart masters, from outside the
>> cluster the ELB does the right thing and takes a master out of service.
>> However, if something tries to talk to the kubernetes API inside the
>> cluster, it seems that kubernetes is unaware the master is missing, and I
>> get failures when I'm serially restarting masters.
>>
>> Is there some way that I can point the kubernetes service to use the load
>> balancer?  Maybe I should update the kubernetes endpoint object to use the
>> ELB IP address instead of the actual master addresses?  Is this a valid
>> approach?  Is there some way with openshift-ansible I can tell the
>> kubernetes service to use the load balancer when it creates the kubernetes
>> service?
>>
>>  Thanks,
>>
>> Joel
>>
>>
>> apiVersion: v1
>> kind: Service
>> metadata:
>>   creationTimestamp: '2018-06-27T06:30:50Z'
>>   labels:
>> component: apiserver
>> provider: kubernetes
>>   name: kubernetes
>>   namespace: default
>>   resourceVersion: '45'
>>   selfLink: /api/v1/namespaces/default/services/kubernetes
>>   uid: a224fd75-79d3-11e8-bd57-0a929ba50438
>> spec:
>>   clusterIP: 172.30.0.1
>>   ports:
>> - name: https
>>   port: 443
>>   protocol: TCP
>>   targetPort: 443
>> - name: dns
>>   port: 53
>>   protocol: UDP
>>   targetPort: 8053
>> - name: dns-tcp
>>   port: 53
>>   protocol: TCP
>>   targetPort: 8053
>>   sessionAffinity: ClientIP
>>   sessionAffinityConfig:
>> clientIP:
>>   timeoutSeconds: 10800
>>   type: ClusterIP
>> status:
>>   loadBalancer: {}
>>
>>
>> apiVersion: v1
>> kind: Endpoints
>> metadata:
>>   creationTimestamp: '2018-06-27T06:30:50Z'
>>   name: kubernetes
>>   namespace: default
>>   resourceVersion: '83743'
>>   selfLink: /api/v1/namespaces/default/endpoints/kubernetes
>>   uid: a22a0283-79d3-11e8-bd57-0a929ba50438
>> subsets:
>>   - addresses:
>>   - ip: 10.2.12.53
>>   - ip: 10.2.12.72
>>   - ip: 10.2.12.91
>> ports:
>>   - name: dns
>> port: 8053
>> protocol: UDP
>>   - name: dns-tcp
>> port: 8053
>> protocol: TCP
>>   - name: https
>> port: 443
>> protocol: TCP
>>
>>
>> ___
>> 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: Binary build info

[Clayton Coleman]

And coming in 3.11 is an experimental command that lets you add a tar file
as a new layer in an image (or as a new “scratch” image), so it’s even
easier to tar up your source code as an image, and have builds trigger off
the image change.  The command is “oc image append —to= [layer as
tar.gz]” and does not require a local container runtime.

On Sep 10, 2018, at 9:42 AM, Ben Parees  wrote:



On Mon, Sep 10, 2018 at 4:25 AM, Jean-Francois Maury 
wrote:

> Hello,
>
> I have a question about binary builds. Once a binary build has been
> created through the instanciatebinary operation, can we use the clone
> operation to respawn a new build ? Will it use the previous input ?
>

Unfortunately not.  The content you upload to the build is streamed into
that build instance but not preserved anywhere, so it is not possible to
"rerun" that build w/o supplying the binary input again.

If you want a rerunnable binary build I would suggest doing a chained build
in which you:

1) perform a binary build that layers your uploaded content into an image
2) perform the "real" build which uses the "input from an image" feature to
extract the content from the image you produced in (1) and perform the
build.

You can then rerun build (2) at will since the image containing the input
content will still exist.



>
> Thanks
>
> --
>
> JEFF MAURY
>
> Red Hat
>
> 
>
> jma...@redhat.com
> 
> 
> @redhatjobs    redhatjobs
>    @redhatjobs
> 
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>


-- 
Ben Parees | OpenShift

___
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: Reducing toil in resource quota bumping (Andrew Feller)

[Clayton Coleman]

There are a lot of possible ways to automate or improve this.  Part of
the reason we have hesitated to add more complexity was because of the
divergence of use cases.

It usually boils down to asking “who” or “why”. One option for
empowering specific trusted individuals is to write a quick loop to
identify when someone is given access to a project, or just do it via
their membership in a group.  I’ve seen a few people build things like
this, but by design most of them are very simple and use case driven.

> On Sep 4, 2018, at 12:37 PM, Walters, Todd  wrote:
>
> This is a similar option we’d like to have a solution to. We have ‘tech 
> leads’ for projects that are in openshift role that can provision projects. 
> These are typically done via Jenkins job. It would be nice to be able to 
> apply custom project template for each project type so that smaller project 
> may have small project template with smaller quota and could have med and 
> large quotas.
>
> Currently we deploy the default project that has quota/limits set. If an lead 
> or team need additional resources they submit request to my team to adjust.
>
> Thanks,
> Todd
>
>
>Today's Topics:
>
>   1. Re: Reducing toil in resource quota bumping (Andrew Feller)
>
>
>--
>
>Message: 1
>Date: Tue, 4 Sep 2018 09:08:41 -0400
>From: Andrew Feller 
>To: users@lists.openshift.redhat.com
>Subject: Re: Reducing toil in resource quota bumping
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>Yeah, we have heterogenous trust levels between production and
>non-production environments.  This discussion was focused solely on
>non-production environment where project default template is minimal
>footprint and system administrators are in line for increasing project
>resource quotes per developer per project.  Since some projects require
>more resources than others, we want to prevent non-administrators from
>blowing up the cluster with wasteful resource usage but not so confined
>they need someone holding their hands on a regular basis.
>
>
>
> 
> The information contained in this message, and any attachments thereto,
> is intended solely for the use of the addressee(s) and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination, copying, or other use of the transmitted information is
> prohibited. If you received this in error, please contact the sender
> and delete the material from any computer. UNIGROUP.COM
> 
>

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

Re: Atomic Host support on OpenShift 3.11 and up

[Clayton Coleman]

Master right now will be labeled 4.0 when 3.11 branches (happening right
now).  It’s possible we might later cut a 3.12 but no plans at the current
time.

Changes to master will include significant changes as the core is rewired
with operators - you’ll also see much more focus on preparing
openshift/installer and refractors in openshift-ansible that reduce its
scope as the hand-off to operators happens.  Expect churn for the next
months.

On Sep 6, 2018, at 6:23 PM, Daniel Comnea  wrote:

Clayton,

4.0 is that going to be 3.12 rebranded (if we follow the current release
cycle) or 3.13 ?



On Thu, Sep 6, 2018 at 2:34 PM Clayton Coleman  wrote:

> The successor to atomic host will be RH CoreOS and the community
> variants.  That is slated for 4.0.
>
> > On Sep 6, 2018, at 9:25 AM, Marc Ledent  wrote:
> >
> > Hi all,
> >
> > I have read in the 3.10 release notes that Atomic Host is deprecated and
> will nod be supported starting release 3.11.
> >
> > What this means? Is it advisable to migrate all Atomic host vms to
> "standard" RHEL server?
> >
> > Kind regards,
> > Marc
> >
> >
> > ___
> > 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: Atomic Host support on OpenShift 3.11 and up

[Clayton Coleman]

The successor to atomic host will be RH CoreOS and the community
variants.  That is slated for 4.0.

> On Sep 6, 2018, at 9:25 AM, Marc Ledent  wrote:
>
> Hi all,
>
> I have read in the 3.10 release notes that Atomic Host is deprecated and will 
> nod be supported starting release 3.11.
>
> What this means? Is it advisable to migrate all Atomic host vms to "standard" 
> RHEL server?
>
> Kind regards,
> Marc
>
>
> ___
> 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: Reducing toil in resource quota bumping

[Clayton Coleman]

On Sep 4, 2018, at 8:30 AM, Andrew Feller  wrote:

While that is a fair assessment of the situations where this pain point
arises, there should be a better option for facilitating #3 without
allowing #1 or #2 as this is a common problem disrupting both sides of the
situation.

Knee jerk thought would be to modify the ProjectRequest API to allow
requestor to specify anything the ClusterResourceQuota object can control.
This would allow new projects being created to sized right until some
situation to support resizing existing projects can be developed.


If you trust your developers to resize, create a role that you bind to the
namespace / account when you trust them.  Or just add it to edit and they’d
have it by default.

The complicated scenarios are usually when your trust domains are
heterogeneous - it didn’t sound like that was your case.


On Thu, Aug 30, 2018 at 2:46 PM Clayton Coleman  wrote:

> Ultimately you need to ask what you are trying to prevent:
>
> 1. a user from accidentally blowing up the cluster
> 2. malicious users
> 3. an application breaking at runtime because it needs more resources than
> it is allotted
>
> The second one is more what we've been discussing here - being draconian
> up front.  1 is usually where you'd have two quotas - initial, and
> generous, and then just swap them out as needed, possibly via some
> automation.  3 is what most people are most afraid of (failing to meet your
> SLA because you didn't allocate resources).
>
>
>
>
>
> On Thu, Aug 30, 2018 at 2:17 PM Andrew Feller 
> wrote:
>
>> Thanks for the feedback Jessica!
>>
>> Limiting # of projects users can create is definitely one of the things
>> expected, however the question was mostly focused on reducing toil due to
>> changing resource quotas for projects.  The idea with option #1 was
>> restricting devs to 1 project with heftier resources allocated whereas the
>> hope with option #2 was ClusterResourceQuota per developer might relax
>> other options for developers to modify project resource quotas without
>> waiting on system administrators.
>>
>> On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller 
>>> wrote:
>>>
>>>> Has anyone found an effective way to minimize toil between developers
>>>> and system administrators regarding project resource quotas *without
>>>> resorting to letting people do whatever they want unrestrained*?
>>>>
>>>> There are only 2 ideas I can see to address this issue:
>>>>
>>>>1. Removing self-provisioning access, provisioning a single project
>>>>per developer, and giving them admin access to it.
>>>>
>>>>
>>> You can limit the number of self-provisioned projects they can have
>>>
>>> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user
>>>
>>>
>>>>
>>>>1. Create ClusterResourceQuota per developer restricting total
>>>>resources allowed
>>>>
>>>> I don't know how ClusterResourceQuota handle a system administrator
>>>> increasing a project's quotas for a user who is already met their total.
>>>>
>>>
>>> If either a cluster resource quota or a resource quota has been
>>> exceeded, then you you've exceeded quota for that resource and can't make
>>> more.
>>>
>>>
>>>>
>>>> Any feedback is welcomed and appreciated!
>>>> --
>>>>
>>>> [image: BandwidthMaroon.png]
>>>>
>>>> Andy Feller  •  Sr DevOps Engineer
>>>>
>>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>>>
>>>>
>>>> e: afel...@bandwidth.com
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>
>>
>> --
>>
>> [image: BandwidthMaroon.png]
>>
>> Andy Feller  •  Sr DevOps Engineer
>>
>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>
>>
>> e: afel...@bandwidth.com
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>

-- 

[image: BandwidthMaroon.png]

Andy Feller  •  Sr DevOps Engineer

900 Main Campus Drive, Suite 500, Raleigh, NC 27606


e: afel...@bandwidth.com

___
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: 3.9 Default Router Malfunction When 1 of 3 Pods is Down

[Clayton Coleman]

On Sep 2, 2018, at 9:51 AM, Stan Varlamov  wrote:

I think this is the cause. If using the ALB, each target master must have
the Router working. Either this is not documented well enough, or I’m not
reading the docs correctly, but my understanding of how this works was that
the link comes in into some generic receiver, and then OpenShift would take
over from there. With the ALB, the link comes in into the actual designated
master box, and that box, apparently, must have all the means of acting as
a designated oc master. Looks like I may need to remove the masters that I
don’t consider real ones anymore from the ALB targets, and that would take
care of my situation.


I’m really confused what you are trying to do.  You should not front the
apiserver with a router.  The router and the masters are generally best not
to collocate unless your bandwidth requirements are low, but it’s much more
effective to schedule the routers on nodes and keep that traffic separate
from a resiliency perspective.

The routers need the masters to be available (2/3 min) to receive their
route configuration when restarting, but require no interconnection to
serve traffic.



*From:* Clayton Coleman 
*Sent:* Sunday, September 2, 2018 9:31 PM
*To:* Stan Varlamov 
*Cc:* users@lists.openshift.redhat.com
*Subject:* Re: 3.9 Default Router Malfunction When 1 of 3 Pods is Down



When you were experiencing the outage was ALB listing 2/3 healthy
backends?  I’m not as familiar with ALB over ELB, but what you are
describing sounds like the frontend only was able to see one of the pods.


On Sep 2, 2018, at 9:21 AM, Stan Varlamov  wrote:

AWS ALB



*From:* Clayton Coleman 
*Sent:* Sunday, September 2, 2018 9:11 PM
*To:* Stan Varlamov 
*Cc:* users@lists.openshift.redhat.com
*Subject:* Re: 3.9 Default Router Malfunction When 1 of 3 Pods is Down



Routers all watch all routes.  What are you fronting your routers with for
HA?  VRRP?  An F5 or cloud load balancer?  DNS?


On Sep 2, 2018, at 6:18 AM, Stan Varlamov  wrote:

Went through a pretty scary experience of partial and uncontrollable outage
in a 3.9 cluster that happened to be caused by issues in the default out of
the box Router. The original installation had 3 region=infra nodes where
the 3 router pods got installed via the generic ansible cluster
installation. 2 of the 3 nodes where subsequently re-labeled at some point
in the past, and after one node was restarted, over sudden, random routes
started “disappearing”, causing 502s. I noticed that one of the 3 Router
pods was in pending – due to lack of available nodes. Bottom line, till I
got all 3 pods back into operation (tried dropping nodeselector
requirements but ended up re-labeling the nodes back to infra) – the routes
would not come back. I would expect that even one working Router can
control all routes in the cluster – no. I couldn’t find a pattern which
routes were off vs. those that stayed on, and some routes would pop in and
out of operation. Is there something in the Router design that relies on
all its pods working? Appears that individual Router pods are “responsible”
for some routes in the cluster vs. just doing redundancy.







___
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: 3.9 Default Router Malfunction When 1 of 3 Pods is Down

[Clayton Coleman]

When you were experiencing the outage was ALB listing 2/3 healthy
backends?  I’m not as familiar with ALB over ELB, but what you are
describing sounds like the frontend only was able to see one of the pods.

On Sep 2, 2018, at 9:21 AM, Stan Varlamov  wrote:

AWS ALB



*From:* Clayton Coleman 
*Sent:* Sunday, September 2, 2018 9:11 PM
*To:* Stan Varlamov 
*Cc:* users@lists.openshift.redhat.com
*Subject:* Re: 3.9 Default Router Malfunction When 1 of 3 Pods is Down



Routers all watch all routes.  What are you fronting your routers with for
HA?  VRRP?  An F5 or cloud load balancer?  DNS?


On Sep 2, 2018, at 6:18 AM, Stan Varlamov  wrote:

Went through a pretty scary experience of partial and uncontrollable outage
in a 3.9 cluster that happened to be caused by issues in the default out of
the box Router. The original installation had 3 region=infra nodes where
the 3 router pods got installed via the generic ansible cluster
installation. 2 of the 3 nodes where subsequently re-labeled at some point
in the past, and after one node was restarted, over sudden, random routes
started “disappearing”, causing 502s. I noticed that one of the 3 Router
pods was in pending – due to lack of available nodes. Bottom line, till I
got all 3 pods back into operation (tried dropping nodeselector
requirements but ended up re-labeling the nodes back to infra) – the routes
would not come back. I would expect that even one working Router can
control all routes in the cluster – no. I couldn’t find a pattern which
routes were off vs. those that stayed on, and some routes would pop in and
out of operation. Is there something in the Router design that relies on
all its pods working? Appears that individual Router pods are “responsible”
for some routes in the cluster vs. just doing redundancy.







___
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: 3.9 Default Router Malfunction When 1 of 3 Pods is Down

[Clayton Coleman]

Routers all watch all routes.  What are you fronting your routers with for
HA?  VRRP?  An F5 or cloud load balancer?  DNS?

On Sep 2, 2018, at 6:18 AM, Stan Varlamov  wrote:

Went through a pretty scary experience of partial and uncontrollable outage
in a 3.9 cluster that happened to be caused by issues in the default out of
the box Router. The original installation had 3 region=infra nodes where
the 3 router pods got installed via the generic ansible cluster
installation. 2 of the 3 nodes where subsequently re-labeled at some point
in the past, and after one node was restarted, over sudden, random routes
started “disappearing”, causing 502s. I noticed that one of the 3 Router
pods was in pending – due to lack of available nodes. Bottom line, till I
got all 3 pods back into operation (tried dropping nodeselector
requirements but ended up re-labeling the nodes back to infra) – the routes
would not come back. I would expect that even one working Router can
control all routes in the cluster – no. I couldn’t find a pattern which
routes were off vs. those that stayed on, and some routes would pop in and
out of operation. Is there something in the Router design that relies on
all its pods working? Appears that individual Router pods are “responsible”
for some routes in the cluster vs. just doing redundancy.







___
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: Reducing toil in resource quota bumping

[Clayton Coleman]

Ultimately you need to ask what you are trying to prevent:

1. a user from accidentally blowing up the cluster
2. malicious users
3. an application breaking at runtime because it needs more resources than
it is allotted

The second one is more what we've been discussing here - being draconian up
front.  1 is usually where you'd have two quotas - initial, and generous,
and then just swap them out as needed, possibly via some automation.  3 is
what most people are most afraid of (failing to meet your SLA because you
didn't allocate resources).





On Thu, Aug 30, 2018 at 2:17 PM Andrew Feller  wrote:

> Thanks for the feedback Jessica!
>
> Limiting # of projects users can create is definitely one of the things
> expected, however the question was mostly focused on reducing toil due to
> changing resource quotas for projects.  The idea with option #1 was
> restricting devs to 1 project with heftier resources allocated whereas the
> hope with option #2 was ClusterResourceQuota per developer might relax
> other options for developers to modify project resource quotas without
> waiting on system administrators.
>
> On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester 
> wrote:
>
>>
>>
>> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller 
>> wrote:
>>
>>> Has anyone found an effective way to minimize toil between developers
>>> and system administrators regarding project resource quotas *without
>>> resorting to letting people do whatever they want unrestrained*?
>>>
>>> There are only 2 ideas I can see to address this issue:
>>>
>>>1. Removing self-provisioning access, provisioning a single project
>>>per developer, and giving them admin access to it.
>>>
>>>
>> You can limit the number of self-provisioned projects they can have
>>
>> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user
>>
>>
>>>
>>>1. Create ClusterResourceQuota per developer restricting total
>>>resources allowed
>>>
>>> I don't know how ClusterResourceQuota handle a system administrator
>>> increasing a project's quotas for a user who is already met their total.
>>>
>>
>> If either a cluster resource quota or a resource quota has been exceeded,
>> then you you've exceeded quota for that resource and can't make more.
>>
>>
>>>
>>> Any feedback is welcomed and appreciated!
>>> --
>>>
>>> [image: BandwidthMaroon.png]
>>>
>>> Andy Feller  •  Sr DevOps Engineer
>>>
>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>>>
>>>
>>> e: afel...@bandwidth.com
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>
>
> --
>
> [image: BandwidthMaroon.png]
>
> Andy Feller  •  Sr DevOps Engineer
>
> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606
>
>
> e: afel...@bandwidth.com
> ___
> 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

PSA for openshift users - dockerhub will be down for scheduled outage on August 25th

[Clayton Coleman]

Please see https://status.docker.com/ for times.

Remember, if you have autoscaling nodes that need to pull new apps, or have
pods that run with PullAlways, or push builds to the docker hub, while the
hub is down those operations will fail.

Mitigations could include:

1. Disable autoscaling for the duration
2. Use the image mirroring and transparent proxying feature of the
openshift integrated registry (switch the resolutionPolicy for your image
streams to Local on 3.9 or later) to automatically mirror remote images and
serve them from the local registry
3. Disable PullAlways from any deployed workloads so you can leverage
cached local images (if a pod tries to restart while the registry is down
and pull always is set, the new container won’t be started).
4. Push to a different registry than dockerhub, like the integrated
registry or quay.io
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Removed "openshift start node" from origin master

[Clayton Coleman]

That’s the long term direction, now that many extension points are maturing
enough to be useful.  But I’ll caution and say the primary goal is to
reduce maintenance costs, improve upgrade isolation, and maintain the
appropriate level of security, so some of the more nuanced splits might
take much longer.

On Aug 14, 2018, at 6:51 PM, Daniel Comnea  wrote:

Hi Clayton,

Great progress!

So am i right to say that *"**splitting OpenShift up to make it be able to
run on top of kubernetes"* end result will be more like openshift distinct
features turning more like add-ons rather than what we have today?



On Tue, Aug 14, 2018 at 6:17 PM, Clayton Coleman 
wrote:

> As part of the continuation of splitting OpenShift up to make it be able
> to run on top of kubernetes, we just merged https://github.com/
> openshift/origin/pull/20344 which removes "openshift start node" and the
> "openshift start" commands.  This means that the openshift binary will no
> longer include the kubelet code and if you want an "all-in-one" openshift
> experience you'll want to use "oc cluster up".
>
> There should be no impact to end users - starting in 3.10 we already only
> used the kubelet (part of hyperkube binary) and use the
> "openshift-node-config" binary to translate the node-config.yaml into
> kubelet arguments.  oc cluster up has been running in this configuration
> for a while.
>
> integration tests have been changed to only start the master components
>
> ___
> dev mailing list
> d...@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Removed "openshift start node" from origin master

[Clayton Coleman]

As part of the continuation of splitting OpenShift up to make it be able to
run on top of kubernetes, we just merged
https://github.com/openshift/origin/pull/20344 which removes "openshift
start node" and the "openshift start" commands.  This means that the
openshift binary will no longer include the kubelet code and if you want an
"all-in-one" openshift experience you'll want to use "oc cluster up".

There should be no impact to end users - starting in 3.10 we already only
used the kubelet (part of hyperkube binary) and use the
"openshift-node-config" binary to translate the node-config.yaml into
kubelet arguments.  oc cluster up has been running in this configuration
for a while.

integration tests have been changed to only start the master components
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Autoscaling groups

[Clayton Coleman]

It is not possible to do to masters.  You'd need to create a new cluster.

I don't think the node group addition in in official docs yet because it's
still tech preview.  So Ansible is the best you'll get for now.

On Tue, Jul 24, 2018 at 10:04 AM David Conde  wrote:

> Thanks,
>
> Is it possible to also do that with masters post upgrade? Do you have any
> info you could point me at to create the new node groups post upgrade?
>
>
>
> On Tue, Jul 24, 2018 at 3:00 PM Clayton Coleman 
> wrote:
>
>> Upgrading from regular nodes to autoscaling groups is not implemented.
>> You’d have to add new node groups post upgrade and manage it that way.
>>
>> > On Jul 24, 2018, at 7:22 AM, David Conde  wrote:
>> >
>> > I'm in the process of upgrading an origin cluster running on AWS from
>> 3.7 to 3.9 using openshift ansible. I'd like the new instances to be
>> registered in autoscaling groups.
>> >
>> > I have seen that if I create a new origin 3.9 cluster using the AWS
>> playbooks this happens as part of the install, how would I go about
>> ensuring this happens as part of the upgrade from 3.7 to 3.9?
>> >
>> > Thanks,
>> > Dave
>> > ___
>> > 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: Autoscaling groups

[Clayton Coleman]

Upgrading from regular nodes to autoscaling groups is not implemented.
You’d have to add new node groups post upgrade and manage it that way.

> On Jul 24, 2018, at 7:22 AM, David Conde  wrote:
>
> I'm in the process of upgrading an origin cluster running on AWS from 3.7 to 
> 3.9 using openshift ansible. I'd like the new instances to be registered in 
> autoscaling groups.
>
> I have seen that if I create a new origin 3.9 cluster using the AWS playbooks 
> this happens as part of the install, how would I go about ensuring this 
> happens as part of the upgrade from 3.7 to 3.9?
>
> Thanks,
> Dave
> ___
> 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: Managing Routes with a Service Account

[Clayton Coleman]

To access things across all namespaces, you need a ClusterRoleBinding, not
a RoleBinding.  RoleBindings only give you access to the role scoped to the
namespace the RoleBinding is in.

On Tue, Jul 17, 2018 at 10:21 AM Eric D Helms 
wrote:

> Howdy,
>
> I am trying to manage routes via a serviceaccount with the following but
> running into an issue with permission denied:
>
> "User \\\"system:serviceaccount:foreman:foreman-operator\\\" cannot get
> routes in the namespace \\\"foreman\\\""
>
> Resource Definitions:
>
> apiVersion: rbac.authorization.k8s.io/v1beta1
> kind: ClusterRole
> metadata:
>   name: foreman-operator
> rules:
> - apiGroups:
>   - app.theforeman.org
>   resources:
>   - "*"
>   verbs:
>   - "*"
> - apiGroups:
>   - ""
>   resources:
>   - pods
>   - services
>   - endpoints
>   - persistentvolumeclaims
>   - events
>   - configmaps
>   - secrets
>   - serviceaccounts
>   verbs:
>   - "*"
> - apiGroups:
>   - apps
>   resources:
>   - deployments
>   - daemonsets
>   - replicasets
>   - statefulsets
>   verbs:
>   - "*"
> - apiGroups:
>   - batch
>   resources:
>   - jobs
>   verbs:
>   - "*"
> - apiGroups:
>   - route.openshift.io
>   resources:
>   - routes
>   - routes/status
>   verbs:
>   - create
>   - delete
>   - deletecollection
>   - get
>   - list
>   - patch
>   - update
>   - watch
> - apiGroups:
>   - rbac.authorization.k8s.io
>   resources:
>   - roles
>   verbs:
>   - "*"
>
> ---
>
> kind: RoleBinding
> apiVersion: rbac.authorization.k8s.io/v1beta1
> metadata:
>   name: foreman-account-app-operator
>   namespace: foreman
> subjects:
> - kind: ServiceAccount
>   name: foreman-operator
> roleRef:
>   kind: ClusterRole
>   name: foreman-operator
>   apiGroup: rbac.authorization.k8s.io
>
> ---
>
> apiVersion: v1
> kind: ServiceAccount
> metadata:
>   name: foreman-operator
>
>
> --
> Eric D. Helms
> Red Hat Engineering
> Ph.D. Student - North Carolina State University
> ___
> 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: How to make 172.30.0.1 (kubernetes service) health checked?

[Clayton Coleman]

In OpenShift 3.9, when a master goes down the endpoints object should be
updated within 15s (the TTL on the record for the master).  You can check
the value of "oc get endpoints -n default kubernetes" - if you still see
the master IP in that list after 15s then something else is wrong.

On Wed, Jun 27, 2018 at 9:33 AM, Joel Pearson  wrote:

> Hi,
>
> I'm running OpenShift 3.9 on AWS with masters in HA mode using Classic
> ELB's doing TCP load balancing.  If I restart masters, from outside the
> cluster the ELB does the right thing and takes a master out of service.
> However, if something tries to talk to the kubernetes API inside the
> cluster, it seems that kubernetes is unaware the master is missing, and I
> get failures when I'm serially restarting masters.
>
> Is there some way that I can point the kubernetes service to use the load
> balancer?  Maybe I should update the kubernetes endpoint object to use the
> ELB IP address instead of the actual master addresses?  Is this a valid
> approach?  Is there some way with openshift-ansible I can tell the
> kubernetes service to use the load balancer when it creates the kubernetes
> service?
>
>  Thanks,
>
> Joel
>
>
> apiVersion: v1
> kind: Service
> metadata:
>   creationTimestamp: '2018-06-27T06:30:50Z'
>   labels:
> component: apiserver
> provider: kubernetes
>   name: kubernetes
>   namespace: default
>   resourceVersion: '45'
>   selfLink: /api/v1/namespaces/default/services/kubernetes
>   uid: a224fd75-79d3-11e8-bd57-0a929ba50438
> spec:
>   clusterIP: 172.30.0.1
>   ports:
> - name: https
>   port: 443
>   protocol: TCP
>   targetPort: 443
> - name: dns
>   port: 53
>   protocol: UDP
>   targetPort: 8053
> - name: dns-tcp
>   port: 53
>   protocol: TCP
>   targetPort: 8053
>   sessionAffinity: ClientIP
>   sessionAffinityConfig:
> clientIP:
>   timeoutSeconds: 10800
>   type: ClusterIP
> status:
>   loadBalancer: {}
>
>
> apiVersion: v1
> kind: Endpoints
> metadata:
>   creationTimestamp: '2018-06-27T06:30:50Z'
>   name: kubernetes
>   namespace: default
>   resourceVersion: '83743'
>   selfLink: /api/v1/namespaces/default/endpoints/kubernetes
>   uid: a22a0283-79d3-11e8-bd57-0a929ba50438
> subsets:
>   - addresses:
>   - ip: 10.2.12.53
>   - ip: 10.2.12.72
>   - ip: 10.2.12.91
> ports:
>   - name: dns
> port: 8053
> protocol: UDP
>   - name: dns-tcp
> port: 8053
> protocol: TCP
>   - name: https
> port: 443
> protocol: TCP
>
>
> ___
> 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: Log tracing on configmaps modifications - or other resources

[Clayton Coleman]

If you have api audit logging on (see docs for master-config) you would see
who edited the config map and what time.

On Jun 27, 2018, at 1:59 PM, leo David  wrote:

Hello everyone,
I'm encountering this situation on OS Origin 3.9, in which someone whith
full acces in a particular namespace modified a ConfigMap and broke a
service.
Is there a way to trace who / when edited a resource in OpenShift - as
security concerns ?
Thank you very much !

-- 
*Leo David*
*  DevOps*
 *Syncrasy LTD*
www.syncrasy.io

___
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

OpenShift v3.10.0-rc.0 has been published

[Clayton Coleman]

Clients and binaries have been pushed to GitHub
https://github.com/openshift/origin/releases/tag/v3.10.0-rc.0 and images
are available on the DockerHub.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: simple hello world in python keeps crashing how to see why?

[Clayton Coleman]

Find the name of one of your crashing pods and run:

$ oc debug POD_NAME

That'll put you into a copy of that pod at a shell and you can debug
further from there.


On Mon, May 21, 2018 at 5:04 PM, Brian Keyes  wrote:

> I have an very very simple hello python
>
>
> #start loop
> for x in range(0, 30):
> print ("hello python ")
>
> but every time I run this on openshift it keeps crashing , why , would it
> be best to scale this up so it is on all worker nodes let it crash and ssh
> into the worker node and look at the docker logs ?
>
> it has 2gb of ram allocated so I am not thinking that this is a memory
> issue
>
> any advice ?
> --
> thanks 
>
>
> ___
> 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: How to best access registry from scripts

[Clayton Coleman]

oc serviceaccount get-token

Is a little easier for scripting

On May 11, 2018, at 10:49 PM, Mohamed Lrhazi  wrote:

I got it ! Thanks!

» oc describe secret robot-token-6w99j


On Fri, May 11, 2018 at 10:38 PM, Mohamed Lrhazi  wrote:

> One more quick question ;)
>
> I created a service acount, how do I get the password or token I would use
> in docker to pull images?
>
> » oc describe sa robot
> Name:robot
> Namespace:   saml-idp-server
> Labels:  
> Annotations: 
> Image pull secrets:  robot-dockercfg-k7dqm
> Mountable secrets:   robot-token-7scfm
>  robot-dockercfg-k7dqm
> Tokens:  robot-token-6w99j
>  robot-token-7scfm
> Events:  
>
> Thank you so much.
>
>
> On Fri, May 11, 2018 at 10:25 PM, Mohamed Lrhazi  wrote:
>
>> Thanks Ben!
>>
>>
>>
>> On Fri, May 11, 2018 at 10:16 PM, Ben Parees  wrote:
>>
>>>
>>>
>>>
>>>
>>> On Fri, May 11, 2018, 22:11 Mohamed Lrhazi  wrote:
>>>
 Hello,

 The registry requires token based authentication which seems to be an
 expiring token.
 How would I access docker images remotely, from a cronjob task? Is
 there a way to make an image publicly available? or a way to get a
 permanent token?

>>>
>>> Service account tokens don't expire, create a service account and use
>>> its token.
>>>
>>>
 https://docs.openshift.org/latest/install_config/registry/ac
 cessing_registry.html#access-user-prerequisites

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

>>>
>>
>>
>> --
>> Thanks,
>> Mohamed.
>>
>
>
>
> --
> Thanks,
> Mohamed.
>



-- 
Thanks,
Mohamed.

___
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: Issue with Pumba

[Clayton Coleman]

If you want to access the docker socket your pod / container must be
privileged, since the docker socket gives the pod full access to the host.
Set the privileged Boolean on the container’s security context

On May 10, 2018, at 9:43 AM, Mohmmed, Osman X <
osman.x.mohm...@healthpartners.com> wrote:

Hello,



I am trying to run Pumba in a pod and it seems to start well but resulting
in somekind of security error as mentioned below-



Also I tried to chmod 777 to docker.sock but to no effect.



time="2018-05-10T16:36:16Z" level=error msg="Got permission denied while
trying to connect to the Docker daemon socket at
unix:///var/run/docker.sock: Get
http://%2Fvar%2Frun%2Fdocker.sock/containers/json?limit=0:
dial unix /var/run/docker.sock: connect: permission denied"





Thanks in advance for your help,

Osman.



--

This e-mail and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom they are
addressed. If you are not the intended recipient or the individual
responsible for delivering the e-mail to the intended recipient, please be
advised that you have received this e-mail in error and that any use,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.

If you have received this communication in error, please return it to the
sender immediately and delete the original message and any copy of it from
your computer system. If you have any questions concerning this message,
please contact the sender. Disclaimer R001.0

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

Re: Resource limits - an "initial delay" or "max duration" would be really handy

[Clayton Coleman]

Resource limits are fixed because we need to make a good scheduling
decision for the initial burst you’re describing (the extremely high cpu at
the beginning).  Some applications might also need similar cpu on restart.
Your workload needs to “burst”, so setting your cpu limit to your startup
peak and your cpu request to a reasonable percentage of the long term use
is the best way to ensure the scheduler can put you on a node that can
accommodate you.  No matter what, if you want the cpu at the peak we have
to schedule you somewhere you can get the peak cpu.

The longer term approach that makes this less annoying is the feedback loop
between actual used resources on a node for running workloads and requested
workloads, and the eviction and descheduling agents (which attempt to
rebalance nodes by achuffling workloads around).

For the specific case of an app where you know for sure the processes will
use a fraction of the initial limit, you can always voluntarily limit your
own cpu at some time after startup.  That could be a side agent that puts a
more restrictive cgroup limit in place on the container after it has been
up a few minutes.

On May 5, 2018, at 9:57 AM, Alan Christie 
wrote:

I like the idea of placing resource limits on applications running in the
cluster but I wonder if there’s any advice for defining CPU “limits" that
are more tolerant of application start-up behaviour?  Something like the
initial delay on a readiness or liveness probe for example? It just seems
like a rather obvious property of any limit. The ones available are just
too “hard".

One example, and I’m sure this must be common to many applications, is an
application that consumes a significant proportion of the CPU during
initialisation but then, in its steady-state, falls back to a much lower
and non-bursty behaviour. I’ve attached a screenshot of one such
application. You can see that for a very short period of time, exclusive to
initialisation, it consumes many more cycles than the post-initialisation
stage.


During initialisation CPU demand tends to fall and memory use tends to rise.

I suspect that what I’m seeing during this time is OpenShift “throttling”
my app (understandable given the parameters available) and it then fails to
pass through initialisation fast enough to satisfy the readiness/liveness
probe and then gets restarted. Again, and again.

I cannot use any sensible steady-state limit (i.e. one that prevents the
normal stead-state behaviour from deviating) without the application
constantly being forced to throttle and potentially reboot during
initialisation.

In this example I’d like to set a a perfectly reasonable CPU limit of
something like 5Mi (because, after the first minute of execution it should
never deviate from the steady-state level). Sadly I cannot set a low level
because OpenShift will not let the application start (for reasons already
explained) as its initial but very brief CPU load exceeds any “reasonable"
level I set.

I can get around this by defining an abnormally large cpu limit but, to me,
using an “abnormal” level sort of defeats the purpose of a limit.

*Aren’t resource limits missing one vital parameter, “duration" or "initial
delay”.*

Maybe this is beyond the resources feature and has to be deferred to
something like prometheus? But can prometheus take actions rather than just
monitor and alert? And, even if it could, employing prometheus may seem to
some like "using a sledgehammer to crack a nut”.

Any advice on permitting bursty applications within the cluster but also
using limits would be most appreciated.

Alan Christie

___
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

Changes to origin and OCP images in 3.10

[Clayton Coleman]

https://github.com/openshift/origin/pull/19509 has been merged and does two
things:

First, and most important, it puts our images and binaries on a diet:

1. oc is now 110M instead of 220M
2. most origin images were 1.26GB uncompressed (300 or so on the wire) are
now half that size (150 on the wire)

The size of the binary was mostly due to people accidentally or
intentionally taking import dependencies from 'oc' into the kubelet, the
controllers, or the apiservers.  Those links are cut and we'll be putting
in protections to prevent accidental growth.

Changes to our images and how they are split out:

1. openshift/origin and openshift/node are now dead (in both OCP and Origin)
1a. We stopped publishing or using origin-sti-build - both docker and s2i
builds now use the origin-docker-build image
2. openshift/origin's closest equivalent is openshift/origin-control-plane
which has the openshift and oc binaries in it
3. openshift/node is now called openshift/origin-node, and has some other
changes described below
4. the hypershift binary (launches the openshift api and controllers) is in
openshift/origin-hypershift
5. the hyperkube binary (launches the kube api, controllers, and kubelet)
is in openshift/origin-hyperkube
6. two new images openshift/origin-test and openshift/origin-cli have been
created that contain the e2e binary and the cli binary

Two new RPMs have been created that contain just hyperkube and just
hypershift

The node image in 3.10 will continue to have the openshift binary and
hyperkube.  Starting in 3.11 we will likely rename the node image to
openshift/origin-sdn and remove the kubelet and openshift logic from it.

As part of removing our direct go dependency on the kubelet, a new binary
openshift-node-config has been created that does exactly one thing - reads
node-config.yaml and converts it to kubelet arguments.  In 3.11 we will
switch ansible over from calling openshift start node to a calling
openshift-node-config.

The new image separation will be mirrored into OCP, and oc cluster up now
reacts to the changes.  No ansible changes are necessary in 3.10.

If you see oddities because you depended on a particular binary being in
one of our images, please file a bug to me.

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

Re: Origin 3.9 (oc cluster up) doesnt use registry-mirror for internal registry

[Clayton Coleman]

On Apr 19, 2018, at 4:44 AM, marc.schle...@sdv-it.de wrote:

Hello everyone

I was asking this question already on the Openshift Google Group but was
redirected to this list in the hope to find someone who knows the details
about the current "oc cluster up" command.


I am facing some trouble using the "oc cluster up" command within our
corporate environment. The main pain-point is that no external registry is
available from inside our network. The only way to pull images is via a
proxy registry (which mirror dockerhub and the redhat registry).

So I configured my local Docker daemon to use this registry by specifying
"insecure-registries" and "registry-mirrors". Especially the mirror is
important because it causes Docker to look at the specified registry first.
By configuring Docker this way, the command "oc cluster up" can pull the
necessary images.

Unfortunately, when running Openshift and adding a deployment based on an
template/imagestream, no deployment happens. Message is: A new deployment
will start automatically when an image is pushed to openshift/jenkins:2
.

When checking the imagestreams I can see


$ oc get is -n openshift
NAME DOCKER REPOTAGS
 UPDATED
dotnet   172.30.1.1:5000/openshift/dotnet   2.0
dotnet-runtime   172.30.1.1:5000/openshift/dotnet-runtime   2.0
httpd172.30.1.1:5000/openshift/httpd2.4
jenkins  172.30.1.1:5000/openshift/jenkins  1,2
mariadb  172.30.1.1:5000/openshift/mariadb  10.1,10.2
mongodb  172.30.1.1:5000/openshift/mongodb  2.4,2.6,3.2 + 1
more...
mysql172.30.1.1:5000/openshift/mysql5.7,5.5,5.6
nginx172.30.1.1:5000/openshift/nginx1.10,1.12,1.8
nodejs   172.30.1.1:5000/openshift/nodejs   0.10,4,6 + 1
more...
perl 172.30.1.1:5000/openshift/perl 5.16,5.20,5.24
php  172.30.1.1:5000/openshift/php  5.5,5.6,7.0 + 1
more...
postgresql   172.30.1.1:5000/openshift/postgresql   9.4,9.5,9.6 + 1
more...
python   172.30.1.1:5000/openshift/python   3.4,3.5,3.6 + 2
more...
redis172.30.1.1:5000/openshift/redis3.2
ruby 172.30.1.1:5000/openshift/ruby 2.0,2.2,2.3 + 1
more...
wildfly  172.30.1.1:5000/openshift/wildfly  10.0,10.1,8.1 +
1 more...


It seems the Images are not available in the internal docker registry
(inside kubernetes) and they are not pulled on the host either.



$ docker images
REPOSITORY TAG IMAGE ID
 CREATED SIZE
openshift/origin-web-console   v3.9.0  60938911a1f9
11 days ago 485MB
openshift/origin-docker-registry   v3.9.0  2663c9df9123
11 days ago 455MB
openshift/origin-haproxy-routerv3.9.0  c70d45de5384
11 days ago 1.27GB
openshift/origin-deployer  v3.9.0  378ccd170718
11 days ago 1.25GB
openshift/origin   v3.9.0  b5f178918ae9
11 days ago 1.25GB
openshift/origin-pod   v3.9.0  1b36bf755484
11 days ago 217MB

I would expect that the containerized Openshift variant uses the
configuration provided by the Docker installation on the host-system.


I've also tried to Import an imagestream manually but it failed because our
proxy-registry is not whitelisted


$ oc import-image my-jenkins --from=docker-proxy.de:5000/openshift/jenkins-2
-centos7 --confirm
The ImageStream "my-jenkins" is invalid: spec.tags[latest].from.name:
Forbidden: registry "*docker-proxy.de:5000* "
not allowed by whitelist: "*172.30.1.1:5000* ", "
*docker.io:443* ", "*.*docker.io:443*
", "*.*redhat.com:443* ", and
5 more ..



Is there any way to redirect the pull of the imagestreams to our corporate
Proxy?
Or can I modify the imagestreams somehow to hardcode the registry?


You can update the image streams to change the registry.



best regards
Marc

___
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: Can we use 'Run in privileged mode' in the Jenkins Kubernetes Pod Template?

[Clayton Coleman]

Privileged allows everything that anyuid allows

On Apr 17, 2018, at 11:20 AM, Alan Christie <
achris...@informaticsmatters.com> wrote:

Thanks Clayton. That’s worked.

I’m not sure whether I also need to do an "*oc adm policy add-scc-to-user
anyuid -z ${SERVICE_ACCOUNT}"* (which I have done) but I am now able to
build Docker container images in a Jenkins pipeline using a buildah
slave-agent! That’s neat.

The Dockerfile/image source that builds the Jenkins slave-agent and the
(rather fat) resultant agent image are public...

https://github.com/alanbchristie/openshift-jenkins-buildah-slave
https://hub.docker.com/r/alanbchristie/jenkins-slave-buildah-centos7/


On 17 Apr 2018, at 00:39, Clayton Coleman <ccole...@redhat.com> wrote:

Like any other user, to run privileged an administrator must grant access
to the Jenkins service account to launch privileged pods.  That’s done by
granting the service account the slave pod runs as the privileged SCC:

oc adm policy add-scc-to-user -z SERVICE_ACCT privileged

On Apr 16, 2018, at 2:46 PM, Alan Christie <achris...@informaticsmatters.com>
wrote:

I’m trying to get around building Docker containers in a Jenkins
slave-agent (because the Docker socket is not available). Along comes
`buildah` claiming to be a lightweight OCI builder so I’ve built a
`buildah` Jenkins slave agent based on the
`openshift/jenkins-slave-maven-centos7` image (
https://github.com/alanbchristie/openshift-jenkins-buildah-slave.git).

Nice.

Sadly…

…the agent appears useless because buildah needs to be run as root!!!

So I walk from one problem into another.

The wonderfully named option in Jenkins -> Manage Jenkins -> Configure
System -> Kubernetes Pod Template -> "Run in privileged mode" was so
appealing I just had to click it!

But … sigh ... I still can’t run as root, instead I get the **Privileged
containers are not allowed provider restricted** error.

This has probably been asked before but...

   1. Is there anything that can be done to run slave-agents as root? (I
   don't want a BuildConfig, I want to run my existing complex pipelines which
   also build docker images in a Jenkins agent)
   2. If not, is someone thinking about supporting this?

Alan Christie


___
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: Can we use 'Run in privileged mode' in the Jenkins Kubernetes Pod Template?

[Clayton Coleman]

Like any other user, to run privileged an administrator must grant access
to the Jenkins service account to launch privileged pods.  That’s done by
granting the service account the slave pod runs as the privileged SCC:

oc adm policy add-scc-to-user -z SERVICE_ACCT privileged

On Apr 16, 2018, at 2:46 PM, Alan Christie 
wrote:

I’m trying to get around building Docker containers in a Jenkins
slave-agent (because the Docker socket is not available). Along comes
`buildah` claiming to be a lightweight OCI builder so I’ve built a
`buildah` Jenkins slave agent based on the
`openshift/jenkins-slave-maven-centos7` image (
https://github.com/alanbchristie/openshift-jenkins-buildah-slave.git).

Nice.

Sadly…

…the agent appears useless because buildah needs to be run as root!!!

So I walk from one problem into another.

The wonderfully named option in Jenkins -> Manage Jenkins -> Configure
System -> Kubernetes Pod Template -> "Run in privileged mode" was so
appealing I just had to click it!

But … sigh ... I still can’t run as root, instead I get the **Privileged
containers are not allowed provider restricted** error.

This has probably been asked before but...

   1. Is there anything that can be done to run slave-agents as root? (I
   don't want a BuildConfig, I want to run my existing complex pipelines which
   also build docker images in a Jenkins agent)
   2. If not, is someone thinking about supporting this?

Alan Christie


___
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: Adding trusted CA into application pod

[Clayton Coleman]

You would add your CA to the master’s trust bundle (ca.crt or ca-bundle.crt
on each master, usually via Ansible), which is then distributed to all
containers as /var/run/secrets/kubernetes.io/serviceaccount/ca.crt and
available for many default actions like fetching source.  However, if you
are trying to add trusted CAs for other actions not controlled by OpenShift
(your applications) you’d need to add your CA to the trust bundle in your
images following the image’s OS instructions.  You *can* mount CAs as
secrets into pods, but that usually involves more work and putting it into
your images simplifies a lot of things.

https://access.redhat.com/solutions/3110231covers some of this.

On Apr 14, 2018, at 2:19 PM, Genadi Postrilko  wrote:

Hello all,

I am running OCP 3.7 in air gaped, on premise enviroment with our own
certificate authority.
I'm attempting to deploy application which uses external services.
In virtual machine the application works, because all the needed
certificate authorities are in the OS trusted store.
But when i tried to deploy the same application in OCP, I'm struggling to
add a certificate as trusted ca.
One of the common use cases in our environment is in the build process of
nodejs s2i, in which our access npm registry failed because of the lack of
CA trust.
Other pre-built images with our applications also need a way to mount
secret as trusted CA.

Thank you,

Ron Cohen

___
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: Empty /etc/cni/net.d with Ansible installer on 3.7 and 3.9

[Clayton Coleman]

I don’t think we’ve seen it elsewhere (certainly not repeatedly), which
probably indicates something specific to your environment, inventory, or
base system.

I suggested restarting because this is all the same debugging info we’d ask
in a bug - knowing whether it’s transient and clears on a restart narrows
the issue down (likely to be a bug in the core code).

On Apr 14, 2018, at 4:30 AM, Alan Christie <achris...@informaticsmatters.com>
wrote:

Thanks Clayton,

I’ll take a look a closer look next week because the solution seems to be
fixing the symptoms, not the cause and I’d like to get to a stage where we
don’t need to patch the installation and restart-it.

This happens pretty much *every time* that I install 3.7 or 3.9 on AWS and
a significant number of times on OpenStack.

Has this been reported by others because it’s so common that we can't be
the only ones seeing this?

Alan


On 13 Apr 2018, at 21:35, Clayton Coleman <ccole...@redhat.com> wrote:

Can not find allocated subnet usually means the master didn’t hand out a
chunk of SDN IPs to that node.  Check the master’s origin-master-controller
logs and look for anything that relates to the node name mentioned in your
error.  If you see a problem, try restarting the origin-master-controllers
processes on all nodes.

On Apr 13, 2018, at 2:26 PM, Alan Christie <achris...@informaticsmatters.com>
wrote:

What’s wrong with the post-3.6 OpenShift/Origin release?

I build my cluster with Terraform and OpenShift 3.6 (on AWS) is wonderfully
stable and I have no problem creating clusters. But, with both 3.7 and 3.9,
I just cannot start a cluster without encountering at least one node with
an empty */etc/cni/net.d*.

This applies to 3.7 and 3.9 on AWS and two OpenStack providers. In all
cases the Ansible installer enters the "*RUNNING HANDLER [openshift_node :
restart node]"* task but this, for the vast majority of installations on
OpenStack and every single attempt in AWS, always fails. I’m worried that
I’ve got something clearly very wrong and have had to return to 3.6 to get
anything done.

RUNNING HANDLER [openshift_node : restart
openvswitch] 

Friday 13 April 2018  13:19:09 +0100 (0:00:00.062)   0:09:28.744
**
changed: [18.195.236.210]
changed: [18.195.126.190]
changed: [18.184.65.88]

RUNNING HANDLER [openshift_node : restart openvswitch
pause] 
**
Friday 13 April 2018  13:19:09 +0100 (0:00:00.720)   0:09:29.464
**
skipping: [18.195.236.210]

RUNNING HANDLER [openshift_node : restart
node] 
***
Friday 13 April 2018  13:19:09 +0100 (0:00:00.036)   0:09:29.501
**
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (1 retries left).
FAILED - RETRYING: restart node (1 retries left).
FAILED - RETRYING: restart node (1 retries left).
fatal: [18.195.236.210]: FAILED! => {"attempts": 3, "changed": false,
"msg": "Unable to restart service origin-node: Job for origin-node.service
failed because the control process exited with error code. See \"systemctl
status origin-node.service\" and \"journalctl -xe\" for details.\n"}
fatal: [18.195.126.190]: FAILED! => {"attempts": 3, "changed": false,
"msg": "Unable to restart service origin-node: Job for origin-node.service
failed because the control process exited with error code. See \"systemctl
status origin-node.service\" and \"journalctl -xe\" for details.\n"}
fatal: [18.184.65.88]: FAILED! => {"attempts": 3, "changed": false, "msg":
"Unable to restart service origin-node: Job for origin-node.service failed
because the control process exited with error code. See \"systemctl status
origin-node.service\" and \"journalctl -xe\" for details.\n"}


When I jump onto a suspect node after the failure I find*/etc/cni/net.d* is
empty and the journal contains the message "*No networks found in
/etc/cni/net.d*”...

-- The start-up result is done.
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
origin-master-controllers[26728]: I0413 12:23:44.850154   26728
leaderelection.go:179] attempting to acquire leader lease...
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
origin-node[26683]: W0413 12:23:44.933963   26683 cni.go:189] Unable to
update cni config: No networks found in /etc/cni/net.d
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
ori

Re: Empty /etc/cni/net.d with Ansible installer on 3.7 and 3.9

[Clayton Coleman]

Can not find allocated subnet usually means the master didn’t hand out a
chunk of SDN IPs to that node.  Check the master’s origin-master-controller
logs and look for anything that relates to the node name mentioned in your
error.  If you see a problem, try restarting the origin-master-controllers
processes on all nodes.

On Apr 13, 2018, at 2:26 PM, Alan Christie 
wrote:

What’s wrong with the post-3.6 OpenShift/Origin release?

I build my cluster with Terraform and OpenShift 3.6 (on AWS) is wonderfully
stable and I have no problem creating clusters. But, with both 3.7 and 3.9,
I just cannot start a cluster without encountering at least one node with
an empty */etc/cni/net.d*.

This applies to 3.7 and 3.9 on AWS and two OpenStack providers. In all
cases the Ansible installer enters the "*RUNNING HANDLER [openshift_node :
restart node]"* task but this, for the vast majority of installations on
OpenStack and every single attempt in AWS, always fails. I’m worried that
I’ve got something clearly very wrong and have had to return to 3.6 to get
anything done.

RUNNING HANDLER [openshift_node : restart
openvswitch] 

Friday 13 April 2018  13:19:09 +0100 (0:00:00.062)   0:09:28.744
**
changed: [18.195.236.210]
changed: [18.195.126.190]
changed: [18.184.65.88]

RUNNING HANDLER [openshift_node : restart openvswitch
pause] 
**
Friday 13 April 2018  13:19:09 +0100 (0:00:00.720)   0:09:29.464
**
skipping: [18.195.236.210]

RUNNING HANDLER [openshift_node : restart
node] 
***
Friday 13 April 2018  13:19:09 +0100 (0:00:00.036)   0:09:29.501
**
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (3 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (2 retries left).
FAILED - RETRYING: restart node (1 retries left).
FAILED - RETRYING: restart node (1 retries left).
FAILED - RETRYING: restart node (1 retries left).
fatal: [18.195.236.210]: FAILED! => {"attempts": 3, "changed": false,
"msg": "Unable to restart service origin-node: Job for origin-node.service
failed because the control process exited with error code. See \"systemctl
status origin-node.service\" and \"journalctl -xe\" for details.\n"}
fatal: [18.195.126.190]: FAILED! => {"attempts": 3, "changed": false,
"msg": "Unable to restart service origin-node: Job for origin-node.service
failed because the control process exited with error code. See \"systemctl
status origin-node.service\" and \"journalctl -xe\" for details.\n"}
fatal: [18.184.65.88]: FAILED! => {"attempts": 3, "changed": false, "msg":
"Unable to restart service origin-node: Job for origin-node.service failed
because the control process exited with error code. See \"systemctl status
origin-node.service\" and \"journalctl -xe\" for details.\n"}


When I jump onto a suspect node after the failure I find*/etc/cni/net.d* is
empty and the journal contains the message "*No networks found in
/etc/cni/net.d*”...

-- The start-up result is done.
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
origin-master-controllers[26728]: I0413 12:23:44.850154   26728
leaderelection.go:179] attempting to acquire leader lease...
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
origin-node[26683]: W0413 12:23:44.933963   26683 cni.go:189] Unable to
update cni config: No networks found in /etc/cni/net.d
Apr 13 12:23:44 ip-10-0-0-61.eu-central-1.compute.internal
origin-node[26683]: E0413 12:23:44.934447   26683 kubelet.go:2112]
Container runtime network not ready: NetworkReady=false
reason:NetworkPluginNotReady message:docker: network plugin is not ready:
cni config uninitialized
Apr 13 12:23:47 ip-10-0-0-61.eu-central-1.compute.internal
origin-node[26683]: W0413 12:23:47.947200   26683 sdn_controller.go:48]
Could not find an allocated subnet for node:
ip-10-0-0-61.eu-central-1.compute.internal,
Waiting...


Is anyone else seeing this and, more importantly, is there a clear cause
and solution?

I cannot start 3.7 and have been tinkering with it for days on AWS at all
and on OpenStack 3 out of 4 attempts fail. I just tried 3.9 to find the
same failure on AWS and have just given up and returned to the wonderfully
stable 3.6.

Alan Christie



___
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: Install OpenShift Origin 3.9 failed on single node

[Clayton Coleman]

You can try rerunning the install with -vv to get additional debug
information.

What OS and version on Ansible are you using?

On Apr 10, 2018, at 3:24 AM, Yu Wei  wrote:

Hi,
I tried to install openshift origin 3.9 on a single machine and encountered
problems as below,



























*TASK [openshift_node : Install Node package, sdn-ovs, conntrack packages]
*
fatal: [host-10-1-241-74]: FAILED! => {"msg": "|failed expects a string or
unicode"} to retry, use: --limit
@/root/jared/openshift-ansible/playbooks/deploy_cluster.retry PLAY RECAP

host-10-1-241-74   : ok=326  changed=41   unreachable=0
failed=1localhost  : ok=13   changed=0
unreachable=0failed=0INSTALLER STATUS
**
Initialization : Complete (0:00:43) Health Check
: Complete (0:00:05) etcd Install   : Complete (0:00:58) Master
Install : Complete (0:05:03) Master Additional Install  :
Complete (0:00:48) Node Install   : In Progress (0:00:38)
 This phase can be restarted by running:
playbooks/openshift-node/config.yml Failure summary:   1. Hosts:
host-10-1-241-74  Play: Configure containerized nodes
Task: Install Node package, sdn-ovs, conntrack packages  Message:
|failed expects a string or unicode*

I didn't find useful information in docker / journal logs.
How could I fix this problem further?

Thanks,

Jared, (韦煜）
Software developer
Interested in open source software, big data, Linux

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

Fwd: Take the Kubernetes Application Survey

[Clayton Coleman]

OpenShift users!  Please take a moment to participate in the Kubernetes
application survey - your feedback will help make Kubernetes and OpenShift
a better platform.

Thanks!


Begin forwarded message:

*From:* Matt Farina 
*Date:* April 5, 2018 at 11:40:11 AM EDT
*To:* "Kubernetes developer/contributor discussion" <
kubernetes-...@googlegroups.com>,  kubernetes-sig-apps <
kubernetes-sig-a...@googlegroups.com>,  kubernetes-wg-app-def <
kubernetes-wg-app-...@googlegroups.com>, cncf-kubernetes-h...@lists.cncf.io
*Subject:* *Take the Kubernetes Application Survey*

The survey is available at https://goo.gl/forms/ht61kKETiqVR103v1

Backstory: For the past several months the App Def WG has been looking at
how people build applications to run on Kubernetes and tools to work with
them. In order to better understand end users a survey has been created to
learn from a broader audience. The questions have been gathered from a
variety of sources, including sub-project teams, and the resulting data
will be shared with the community at large.

If you build applications for Kubernetes or operates applications on
Kubernetes we ask that you take a few minutes to let us know what you think.

If you would, please share this survey with your networks so we can get
input from a wide audience range.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups
"Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to kubernetes-dev+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-dev/CAMPAG2oYEfgWxt%3DHd7PQTE7TO%2BkSqWN-xc%2BzEjWxBBrm44drZg%40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: [CentOS-devel] CentOS PaaS SIG meeting (2018-03-21)

[Clayton Coleman]

I’m going to retag when the commits merge.

On Mar 27, 2018, at 7:43 PM, Brigman, Larry <larry.brig...@arris.com> wrote:

Shouldn’t that last tag been an -rc0 instead of v3.9.0?



*From:* users-boun...@lists.openshift.redhat.com [
mailto:users-boun...@lists.openshift.redhat.com
<users-boun...@lists.openshift.redhat.com>] *On Behalf Of *Clayton Coleman
*Sent:* Tuesday, March 27, 2018 3:44 PM
*To:* Troy Dawson <tdaw...@redhat.com>
*Cc:* users <us...@redhat.com>; The CentOS developers mailing list. <
centos-de...@centos.org>; dev <d...@lists.openshift.redhat.com>
*Subject:* Re: [CentOS-devel] CentOS PaaS SIG meeting (2018-03-21)



Still waiting for a last couple of regressions to be fixed.  Sorry
everyone, I know you're excited about this.



On Tue, Mar 27, 2018 at 6:04 PM, Troy Dawson <tdaw...@redhat.com> wrote:

I didn't see anything saying that 3.9 was released yet.  Last I heard
they were working on some regressions.
If I missed it, can someone point me at it.  Maybe I just need a
better place to look than the mailling lists.


On Thu, Mar 22, 2018 at 11:01 PM, Jeffrey Zhang <zhang.lei@gmail.com>
wrote:
> hi, openshift origin 3.9 is released already,
> when centos-release-openshift-origin39 repo will be GA? it is still using
> alpha tag now.
>
> https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuildlogs.centos.org%2Fcentos%2F7%2Fpaas%2Fx86_64%2Fopenshift-origin39%2F=01%7C01%7Clarry.brigman%40arris.com%7C44ab399f85214a0db07308d594343d4b%7Cf27929ade5544d55837ac561519c3091%7C1=Yj4F60B72Jqp51E9Y6R1jD6iTTKfuOGP6uySoqcGuro%3D=0>

>

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openshift.redhat.com%2Fopenshiftmm%2Flistinfo%2Fusers=01%7C01%7Clarry.brigman%40arris.com%7C44ab399f85214a0db07308d594343d4b%7Cf27929ade5544d55837ac561519c3091%7C1=dMj9DH7P4e%2Fow7My%2BiZNRZwHVWLM06U%2Bkpt2CDITcbs%3D=0>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: [CentOS-devel] CentOS PaaS SIG meeting (2018-03-21)

[Clayton Coleman]

Still waiting for a last couple of regressions to be fixed.  Sorry
everyone, I know you're excited about this.

On Tue, Mar 27, 2018 at 6:04 PM, Troy Dawson  wrote:

> I didn't see anything saying that 3.9 was released yet.  Last I heard
> they were working on some regressions.
> If I missed it, can someone point me at it.  Maybe I just need a
> better place to look than the mailling lists.
>
>
> On Thu, Mar 22, 2018 at 11:01 PM, Jeffrey Zhang 
> wrote:
> > hi, openshift origin 3.9 is released already,
> > when centos-release-openshift-origin39 repo will be GA? it is still
> using
> > alpha tag now.
> >
> > https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
> >
>
> ___
> 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: Reloading of haproxy

[Clayton Coleman]

The router contains a management process that generates the haproxy
config and manages restarts, as well as gather stats.

> On Mar 27, 2018, at 9:32 AM, abdul nizam  wrote:
>
> Hi all
>
> i can see the haproxy process id is changing whenever i create a route. So 
> that means haproxy servie is reloading whenever i create a route . So my 
> question who is responsible for the reloading of haproxy?
>
>
> Regards,
> Nizam
> ___
> 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: Some frustrations with OpenShift

[Clayton Coleman]

On Mon, Mar 26, 2018 at 11:50 AM, Alfredo Palhares 
wrote:

> Hello everyone,
>
>
> I would like to share some of the frustations that I currently have with
> openshift, which is making me not consider this a base to our container
> infrastcture.
> - No visualization of the cluster out of the box
>

Generally that has been a responsibility of CloudForms / manageiq.  What
sorts of visualizations are you looking for?


>  To me this seems a bit weird that there is no clear way of having
> visualization of te cluster status out, i am strugggling following the
> documentation
>  , my
> ansible playbook is breaking, and I have a simple 1 master and 3 nodes
> setup.
> - Not having the possibility to use kubernestes directly
>

By "use kubernetes" directly do you mean, "Using the kubernetes API's
directly?" or "Using an existing Kubernetes cluster?"  If the former, we
support all kubernetes GA level APIs, so you shouldn't be blocked there.
For the latter, most of the OpenShift security model requires protections
that are compiled into the kube binaries (multi-tenancy, protecting users
from escaping their namespaces), so today if you tried to run openshift on
top of raw kube you would not have any of the security model.


> Since I am running on metal, the idea of openshift would be more to get
> the supporting services of and then using kubernetes deployments.
> - The openshift-ansible is a bit confusing to me
> Altough I see that on the newer versions it is getting better.
>
>
> Just wanted to share some tough, I am not bashing on anything, I do still
> think its a great platform, just getting into it is a bit hard if you are
> not paying for support or deploying on the cloud.
>

We appreciate the feedback


>
> Regards,
> Alfredo Palhares
>
> ___
> 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: OpenShift Origin 3.9.0 release imminent?

[Clayton Coleman]

We found a regression in the subPath behavior, currently waiting for fixes
to land.  I'm probably going to remove the tag and cut another once that
lands.

On Tue, Mar 20, 2018 at 4:06 AM, Joel Pearson  wrote:

> Is the OpenShift Origin 3.9.0 release imminent? I noticed the tag appeared
> 4 days ago, but without any detail yet:
>
> https://github.com/openshift/origin/releases
>
> ___
> 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: Re-Loading Console / API endpoint certificates

[Clayton Coleman]

Other than running an HA setup, no.

On Mar 6, 2018, at 12:56 AM, Alex Stockinger <dajudge...@gmail.com> wrote:

The certificates get properly picked up when I restart the origin docker
container, but I observed that this procedure seems to imply a short
downtime (when not running a HA setup).

Is there a way to have the daemon process pick up the new certificates
without a downtime in my scenario?

Clayton Coleman <ccole...@redhat.com> schrieb am Di., 6. März 2018 um
02:30 Uhr:

> Even when you restart, you aren’t seeing the new certs loaded?
>
> On Mar 5, 2018, at 2:58 AM, Alex Stockinger <dajudge...@gmail.com> wrote:
>
> Hi,
>
> I am trying to secure my OpenShift installation's Console / API on port
> 8443 with let's encrypt certificates. I got this working nicely using the
> servingInfo/namedCertificates section in the master-config.yaml file.
> However upon certificate renewal the process doesn't seem to pick up the
> new certificates.
>
> So my question is: is there a (downtime-free) way to trigger a reload of
> the certificates used for port 8443?
>
> Thanks in advance for your help!
>
> Cheers,
> Alex
>
> ___
> 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: Re-Loading Console / API endpoint certificates

[Clayton Coleman]

Even when you restart, you aren’t seeing the new certs loaded?

On Mar 5, 2018, at 2:58 AM, Alex Stockinger  wrote:

Hi,

I am trying to secure my OpenShift installation's Console / API on port
8443 with let's encrypt certificates. I got this working nicely using the
servingInfo/namedCertificates section in the master-config.yaml file.
However upon certificate renewal the process doesn't seem to pick up the
new certificates.

So my question is: is there a (downtime-free) way to trigger a reload of
the certificates used for port 8443?

Thanks in advance for your help!

Cheers,
Alex

___
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: OpenShift long term plan regarding Routes and Ingresses

[Clayton Coleman]

We have no plan to deprecate routes.  Since ingress are still beta and
there is no clear replacement proposal (and are less expressive) we
plan to continue to offer routes for a long time.  There’s some work
in 3.10 to convert ingress to routes automatically to simplify
transition, which will support the core object and maybe a few
annotations.

> On Mar 2, 2018, at 2:55 AM, Mickaël Canévet  wrote:
>
> both. »

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

Re: Openshift Web UI

[Clayton Coleman]

On Feb 13, 2018, at 10:49 PM, Joel Pearson 
wrote:

The web UI and registry aren’t connected in any way I don’t believe.

If you don’t use the internal registry then you can’t trigger things to
deploy when an image changes, not sure if that matters to you...


Actually you don’t need the registry installed to trigger image updates on
registry tags being updated - that works even without a registry.  You just
won’t be able to push or pull from the registry using the integrated auth.

On Tue, 13 Feb 2018 at 11:26 pm, Polushkin Aleksandr <
aleksandr.polush...@t-systems.ru> wrote:

> Hello everyone !
>
>
>
> I’m playing with Openshift  and at my last installation I disabled
> internal registry and this disabled Web console too.
>
> Am I getting right that it isn’t possible to disable internal registry and
> save the Web UI ?
>
>
>
>
>
> Regards,
>
> Aleksandr
>
>
>
>
> --
>
> T-Systems RUS GmbH
>
> Point of Production
>
> Aleksandr Polushkin
>
> Sr. Configuration Manager
>
> V.O. 13th line, 14B, 199034, St.Petersburg, Russia
>
> Email: aleksandr.polush...@t-systems.ru
>
>
> ___
> 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: ansible failing etcd v2 > v3 migration

[Clayton Coleman]

Is /var/lib/etcd your etcd data directory?  Ie is there anything in that
folder?

On Feb 13, 2018, at 4:50 PM, Feld, Michael (IMS)  wrote:

Hi all,



I am trying to use the ansible playbook to migrate etcd from v2 to v3 for a
3.6.0 origin cluster and it keeps failing with the following:



fatal: [openshift-master]: FAILED! => {"changed": false, "failed": true,
"msg": "Before the migration can proceed the etcd member must write down at
least one snapshot under /var/lib/etcd//member/snap directory."}



I have tried using the release-3.6 branch of openshift-ansible as well as
the master branch migrate.yml playbooks, both give the same result. It
doesn’t even look from the ansible output that it’s even taking a snapshot.
What am I doing wrong?



Mike

--

Information in this e-mail may be confidential. It is intended only for the
addressee(s) identified above. If you are not the addressee(s), or an
employee or agent of the addressee(s), please note that any dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this e-mail in error, please notify the sender of the
error.

___
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: Absence of master-config.yaml

[Clayton Coleman]

When you run “openshift start” by itself that file won’t be created (we
create one in memory).  If you launch with oc cluster up, it should be
inside the container at

 /var/lib/origin/openshift.local.config/master/master-config.yaml




On Feb 7, 2018, at 8:54 PM, Gaurav Ojha  wrote:

Hi,

I have been following the OpenShift Origin documentation, and I have tried
to run OpenShift through the following methods:

1) downloading the binary (unpacked it in /opt/) and started from there
2) ran as a container
3) ran a all-in-one cluster as mentioned on this link
https://github.com/openshift/origin/blob/master/docs/cluster_up_down.md#macos-with-docker-for-mac

It all runs well, and I can create sample projects and everything, but the
entire documentation mentions to modify *master-config.yaml* for a number
of things. And I cant find it anywhere.

I tried to locate the file, looked inside
/opt/origin/openshift.local.config/master and inside /var/lib/openshift as
well, but its just not there on my system.

Is there a step I need to do to get this file? Because if I understand this
correctly, in order to expose any service to the outside world, I need to
modify the external CIDR in this file.

Kindly help me in this regard.

Regards
Gaurav

___
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: No persistent volumes available in OpenShift Origin 3.7.1

[Clayton Coleman]

There’s a job that oc cluster up runs to create host PVs.  You may want to
check that that job ran successfully.  I don’t remember exactly what
namespace it was created it in

On Feb 3, 2018, at 1:10 PM, Tien Hung Nguyen 
wrote:

Hello,

I'm using OpenShift Origin v3.7.1 Client and Server installed on my local
Computer (Mac) via Docker on Mac. I started OpenShift using the command oc
cluster up --host-data-dir /Users/username/oc-data and tried to deploy my
appliocations using a .yml template. However, the deployment stucks because
it gives me the following error:

Events:

  FirstSeen LastSeen Count From SubObjectPath Type Reason Message

  -  -  -  -- ---

  17m 1m 63 persistentvolume-controller Normal FailedBinding no persistent
volumes available for this claim and no storage class is set


After checking my persistent volumes with the command oc get pv, I realized
that my containers don't have any pvs available (Message: No resources
found. ). Please, could you tell me why the new OpenShift Origin 3.7.1
version doesn't create any pvs by default at the beginning?
When I used the old OpenShift Origin 3.6.1 version, I never had that
problem when using the same .yaml template for deployment.

How can I fix that problem?

Regards
Tien

___
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: Headless services without selectors are forbidden in OpenShift

[Clayton Coleman]

You can grant the role to the user to let them set it.  However, that
lets that app escape any network isolation boundaries so the
multitenant network plugin won’t work.

You can also grant that permission to all users if you don’t need the
protection.

> On Jan 30, 2018, at 3:18 PM, Tomas Nozicka  wrote:
>
> I need to direct Route/Service traffic from one namespace to another
> which I have permissions to. (Possibly even the same namespace as
> well.) Reading Kubernetes documentation[1] Services without selectors
> seem to be the way to do it. It requires you to set Endpoints manually
> (e.g. to Service or pod in another namespace) but OpenShift will forbid
> you from doing that.
>
> Error from server (Forbidden): error when creating "endpoints.yaml":
> endpoints "my-service" is forbidden: endpoint address 10.131.xxx.xxx is
> not allowed
>
> It requires you to have endpoints/restricted permission regular users
> don't have.
>
> Is that intentional? What are the reasons? (I think this is the place
> forbidding it [2].)
>
> How else can regular user do this? (Except running "redirecting" pod
> which is fragile.)
>
> Thanks,
> Tomas
>
> [1] - https://kubernetes.io/docs/concepts/services-networking/service/#
> headless-services
> [2] - https://github.com/openshift/origin/blob/de21f148d1ca66ca2bfd2011
> 36c2e99ebda767e9/pkg/service/admission/endpoint_admission.go#L121
>
> ___
> 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: Heptio Contour

[Clayton Coleman]

On Jan 24, 2018, at 2:05 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

Clayton



Good analyses. That is exactly am looking for. Thanks for great info.



Also happy that, you already did prototype and compared with current OCP
routing solution.



Also can u share your thoughts on how ambassador fit this eco system? my
research shows, ambassador would be a good fit for north/south ingress
controller where as Istio would be great fit for east/west service traffic.
Both use Envoy internally.


I do expect all of these proxies to become more interesting over time, and
I agree east/west and north/south are obvious places for differentiation.
We might have multiple interlocking proxies with different focuses.



Then ambassador would be another competitor to contour?



I knew lot of moving parts on routes, ingress and services side but none is
prime time ready for high scale workloads.



-- 

*Srinivas Kotaru*

*From: *Clayton Coleman <ccole...@redhat.com>
*Date: *Wednesday, January 24, 2018 at 10:32 AM
*To: *Srinivas Naga Kotaru <skot...@cisco.com>
*Cc: *users <users@lists.openshift.redhat.com>
*Subject: *Re: Heptio Contour



At this point in time, contour is still pretty new, so expect some rough
edges.  I did a prototype of routes with envoy (similar to contour, but
preserving the router features) a few months back, and identified a set of
challenges which made it not a great fit as a replacement for the OOTB
openshift router



In general, when comparing to haproxy and the general state, here's the
list



PROs (envoy):



* supports http2 natively

* deeper insight into traffic passing through



CONs (envoy):



* scale is not great right now - even using dynamic programming i couldn't
get much above 100 backends before hitting the wall (wouldn't scale to very
large, dense clusters)

* memory use is much higher than haproxy - so another density challenge (I
was using 30GB at 1k backends, vs 5GB for 15k backends that we see with
haproxy)

* web sockets can't be transparent - so you have to run another port for
them instead of sharing the HTTP port

* SNI passthrough not ready, maybe in 6mo

* reencrypt was really hacky, I couldn't get it to work right now (again,
6mo should be fixed)

* general fragility - was easy to break when programming config



CONs (contour, vs openshift router):



* None of the security isolation stuff (preventing one tenant from using
someone else's hostname)

* None of the protection against bad certs (preventing someone from
breaking the router by using someone else's tenant)

* No status reporting back



I think the biggest long term challenge with envoy will be pure scale -
HAProxy is at least two orders of magnitude more efficient right now, and I
think it will be a while before envoy even gets close.  So if you have 10k+
frontends, haproxy is the only game in town.  On ingress vs routes, routes
are still more polished, so it's really just a "do you want the features
routes have that ingress doesn't.



On the other downsides to envoy, I expect to see progress over the next
year or two to fixing it.  I had originally done the prototype expecting
that maybe we would use envoy as the "out of the box" plugin to the router
(continuing to support routes and ingress and all the features, but with
envoy underneath), but the biggest challenge is that envoy isn't really
better than haproxy for the feature set that ingress and routes expose.
Where envoy really shines is in something like istio, where you have a
richer model for the ingress / service definition that can use the extra
bells and whistles.  Ultimately ingress + annotations and routes are both
targeted at "simple, high scale" use of web frontends.  I would expect a
lot of people to have their apps "grow up" and use node ports or istio
ingress as the apps get bigger and more important.  I don't see them as
directly competing.







On Fri, Jan 19, 2018 at 1:36 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

How it is different than Openshift router and what extra benefits it
brings? Anyone educate me to understand differences or possible use cases
where it fit into eco system? Or replacing ingress controller or will it
solve ingress controller 244 address limitations?



https://blog.heptio.com/announcing-contour-0-3-37f4aa7bc6f7







-- 

*Srinivas Kotaru*


___
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: Heptio Contour

[Clayton Coleman]

3.9 will have haproxy 1.8, but the current level of http2 doesn’t
really help applications that aren’t willing to do passthrough.  That
said, passthrough http2 should work.

> On Jan 24, 2018, at 2:54 PM, Tobias Brunner <tob...@tobru.ch> wrote:
>
>> On 24.01.2018 19:31, Clayton Coleman wrote:
>> In general, when comparing to haproxy and the general state, here's the list
>>
>> PROs (envoy):
>>
>> * supports http2 natively
>
> I would say this is a non-issue:
> https://www.mail-archive.com/haproxy@formilux.org/msg28004.html
>
> ---
> HTTP/2 (Willy Tarreau) : HTTP/2 is automatically detected and processed
> in HTTP frontends negociating the "h2" protocol name based on the ALPN
> or NPN TLS extensions. At the moment the HTTP/2 frames are converted to
> HTTP/1.1 requests before processing, so they will always appear as 1.1
> in the logs (and in server logs). No HTTP/2 is supported for now on the
> backend, though this is scheduled for the next steps. HTTP/2 support is
> still considered EXPERIMENTAL, so just like for multi-threading, in case
> of problem you may end up having to disable it for the time it takes to
> solve the issue.
> ---
>
> Now we just need to wait until HAProxy >= 1.8.0 is included in
> OpenShift. Is there any rough ETA for this upgrade available?
>
> Cheers,
> Tobias
>
> ___
> 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: Heptio Contour

[Clayton Coleman]

At this point in time, contour is still pretty new, so expect some rough
edges.  I did a prototype of routes with envoy (similar to contour, but
preserving the router features) a few months back, and identified a set of
challenges which made it not a great fit as a replacement for the OOTB
openshift router

In general, when comparing to haproxy and the general state, here's the list

PROs (envoy):

* supports http2 natively
* deeper insight into traffic passing through

CONs (envoy):

* scale is not great right now - even using dynamic programming i couldn't
get much above 100 backends before hitting the wall (wouldn't scale to very
large, dense clusters)
* memory use is much higher than haproxy - so another density challenge (I
was using 30GB at 1k backends, vs 5GB for 15k backends that we see with
haproxy)
* web sockets can't be transparent - so you have to run another port for
them instead of sharing the HTTP port
* SNI passthrough not ready, maybe in 6mo
* reencrypt was really hacky, I couldn't get it to work right now (again,
6mo should be fixed)
* general fragility - was easy to break when programming config

CONs (contour, vs openshift router):

* None of the security isolation stuff (preventing one tenant from using
someone else's hostname)
* None of the protection against bad certs (preventing someone from
breaking the router by using someone else's tenant)
* No status reporting back

I think the biggest long term challenge with envoy will be pure scale -
HAProxy is at least two orders of magnitude more efficient right now, and I
think it will be a while before envoy even gets close.  So if you have 10k+
frontends, haproxy is the only game in town.  On ingress vs routes, routes
are still more polished, so it's really just a "do you want the features
routes have that ingress doesn't.

On the other downsides to envoy, I expect to see progress over the next
year or two to fixing it.  I had originally done the prototype expecting
that maybe we would use envoy as the "out of the box" plugin to the router
(continuing to support routes and ingress and all the features, but with
envoy underneath), but the biggest challenge is that envoy isn't really
better than haproxy for the feature set that ingress and routes expose.
Where envoy really shines is in something like istio, where you have a
richer model for the ingress / service definition that can use the extra
bells and whistles.  Ultimately ingress + annotations and routes are both
targeted at "simple, high scale" use of web frontends.  I would expect a
lot of people to have their apps "grow up" and use node ports or istio
ingress as the apps get bigger and more important.  I don't see them as
directly competing.



On Fri, Jan 19, 2018 at 1:36 PM, Srinivas Naga Kotaru (skotaru) <
skot...@cisco.com> wrote:

> How it is different than Openshift router and what extra benefits it
> brings? Anyone educate me to understand differences or possible use cases
> where it fit into eco system? Or replacing ingress controller or will it
> solve ingress controller 244 address limitations?
>
>
>
> https://blog.heptio.com/announcing-contour-0-3-37f4aa7bc6f7
>
>
>
>
>
>
>
> --
>
> *Srinivas Kotaru*
>
> ___
> 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: Trying to import Tomcat container

[Clayton Coleman]

How are you providing configuration to the container?  Note that when
openshift creates an app from an image it adds emptyDir volumes to the
created app.  That means the directories end up empty instead of having the
default image content.

Check whether /opt/apache-tomcat-8.5.14/conf/ is a volume in the image, and
if so, you can remove the volume from the app definition (the deployment
config)

On Jan 1, 2018, at 10:15 AM, Hetz Ben Hamo  wrote:

Hi,

I'm trying to import a simple Tomcat container with the 'calendar' webapp
(already in the image) to Openshift Origin (3.7)

As a container, it runs well and I can see the webapp running on the
browser. I save the container, import it to OpenShift - import ok.

Then when I try to create a new app with the Image, I'm getting this error:

Jan 01, 2018 3:09:19 PM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from
[/opt/apache-tomcat-8.5.14/conf/server.xml]
Jan 01, 2018 3:09:19 PM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from
[/opt/apache-tomcat-8.5.14/conf/server.xml]
Jan 01, 2018 3:09:19 PM org.apache.catalina.startup.Catalina start
SEVERE: Cannot start server. Server instance is not configured.

I checked the container, and the /opt/apache-tomcat-8.5.14/conf/server.xml
is right there iin the correct path.

Am I missing something?

Thanks

___
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: Looking for documentation on cloud provider delete node and register node

[Clayton Coleman]

There was an open bug on this previously - I’m having trouble finding it at
the moment.  The node may be racing with the cloud controller and then not
updating the labels.  One workaround is to simply add an “oc label
node/$(hostname) ...” command to the origin-node services as a prestart
command.

On Dec 21, 2017, at 9:13 AM, Ernst, Chad  wrote:



Running Origin 3.6 on AWS, we’ve found that if our EC2 instances go down
for any length of time and come back up (as opposed to the EC2 instance
getting terminated) the nodes are automatically deleted from openshift then
re-registered after the ec2 instance is restarted.  The activity is logged
in /var/log/messages



Dec 20 21:59:30 ip-172-21-21-30 origin-master-controllers: I1220
21:59:30.297638   26242 nodecontroller.go:761] Deleting node (no longer
present in cloud provider): ip-172-21-20-30.ec2.internal

Dec 20 21:59:30 ip-172-21-21-30 origin-master-controllers: I1220
21:59:30.297662   26242 controller_utils.go:273] Recording Deleting Node
ip-172-21-20-30.ec2.internal because it's not present according to cloud
provider event message for node ip-172-21-20-30.ec2.internal

Dec 20 21:59:30 ip-172-21-21-30 origin-master-controllers: I1220
21:59:30.297895   26242 event.go:217] Event(v1.ObjectReference{Kind:"Node",
Namespace:"", Name:"ip-172-21-20-30.ec2.internal",
UID:"36c8dca4-e5c9-11e7-b2ce-0e69b80c212e", APIVersion:"",
ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'DeletingNode'
Node ip-172-21-20-30.ec2.internal event: Deleting Node
ip-172-21-20-30.ec2.internal because it's not present according to cloud
provider





Dec 20 23:10:06 ip-172-21-21-30 origin-master-controllers: I1220
23:10:06.303567   26242 nodecontroller.go:616] NodeController observed a
new Node: "ip-172-21-22-30.ec2.internal"

Dec 20 23:10:06 ip-172-21-21-30 origin-master-controllers: I1220
23:10:06.303597   26242 controller_utils.go:273] Recording Registered Node
ip-172-21-22-30.ec2.internal in NodeController event message for node
ip-172-21-22-30.ec2.internal

Dec 20 23:10:06 ip-172-21-21-30 origin-master-controllers: I1220
23:10:06.303899   26242 event.go:217] Event(v1.ObjectReference{Kind:"Node",
Namespace:"", Name:"ip-172-21-22-30.ec2.internal",
UID:"e850129f-e5da-11e7-ac5e-027542a418ee", APIVersion:"",
ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'RegisteredNode'
Node ip-172-21-22-30.ec2.internal event: Registered Node
ip-172-21-22-30.ec2.internal in NodeController



The issue we are running into is that when the nodes come back they don’t
have all of our labels on them.  They don’t get labelled to run the fluentd
pods “logging-infra-fluentd=true” and my masters aren’t set for “Scheduling
Disabled”.



Can anybody point me to the any doc regarding the automatic registration of
the node from the cloudprovider or knows how to adjust the behavior when a
node is re-registered so they can be tagged properly.



Thanks



Chad


The information contained in this message, and any attachments thereto,
is intended solely for the use of the addressee(s) and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination, copying, or other use of the transmitted information is
prohibited. If you received this in error, please contact the sender
and delete the material from any computer. UNIGROUP.COM


___
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: Several questions about authorization

[Clayton Coleman]

On Mon, Dec 18, 2017 at 5:17 AM, Yu Wei  wrote:

> Hi,
>
> I have several questions about user and authorization management.
>
> 1, How could I remove user from project?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[root@host-10-1-236-92 gpu-test]# oc login -u test1 -p test1 Login
> successful. You have access to the following projects and can switch
> between them with 'oc project ':   * aura test1 Using
> project "aura". [root@host-10-1-236-92 gpu-test]# oc project aura Already
> on project "aura" on server "https://10.1.241.54:8443
> ". [root@host-10-1-236-92 gpu-test]# oc get
> rolebindings Error from server (Forbidden): User "test1" cannot list
> rolebindings in project "aura"*
>
> How should I remove user "test1" from project "aura"?
>

How did you get added to the "aura" project?  If you can't view role
bindings, then you likely don't have the "view" role and you have been
given a more constrained role.  You'd need to ask the person who added you
in that case.


> And how could I find which users belongs to project "aura"?
>

You can see which users have been added with explicit roles by doing "oc
get rolebindings".  You can see who can view the namespace by running "oc
policy who-can get namespace aura" if you have sufficient permissions.


>
> 2, basic-user
>
> When should "basic-user" be used? It seems that basic-user is cluster
> wide. Is my understanding right?
>

There are two types of role bindings - namespace scoped role bindings
(rolebindings) and cluster scoped role bindings (clusterrolebindings).  If
you add someone to a clusterrolebinding they have that role on all
namespaces in the cluster.  If you add someone with a rolebinding, they
only have that permission on the namespace the rolebinding is created in.


>
> 3, user created automatically
>
> When issues the instructions "oc login -u test2 -p test2", user
> "test2" is to be created automatically.
>
> After user creation, which project does created user belong to?
>

None, unless you grant a clusterrolebinding to a group and the new user is
in that group.


>
> Thanks,
>
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
>
> ___
> 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: Unable to get hostPath r/w without privileged: true

[Clayton Coleman]

On Dec 13, 2017, at 8:36 PM, Nick Bartos (nibartos) 
wrote:

I am unable to get a writable hostPath volume for a "privileged: false"
container, even when the container's runAsUser owns the directory on the
host.


The k8s docs say "You either need to run your process as root in a
privileged container or modify the file permissions on the host to be able
to write to a hostPath volume".  I have tried origin via openshift-ansible
release-3.6 and master branches.


I have tried more permutations than I can remember in the manifest,
granting different permissions to the service account, but not matter what,
I cannot get anything inside a container to write to the hostPath without
setting 'privileged: true' for the container.

SELinux is probably preventing you from writing to the host path.
Privileged completely bypasses those protections.  Marking the hostpath you
want to expose as visible to containers should be sufficient (exact selinux
chcon-fu escaping me at the minute).


Here is a fairly simple example:

https://gist.github.com/nbartos/36319ddea5819284d76b667c69d8916f​

___
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: oc cluster up and oauth-proxy

[Clayton Coleman]

When you ran oc cluster up, did you explicitly set the master to run on
127.0.0.1, or did it select that address for you?

OAuth won’t work when the master is set to 127.0.0.1 (nor will a number of
other functions)

On Dec 11, 2017, at 6:38 AM, Simon Pasquier  wrote:

Hi,

I've played with oauth-proxy [1] on my local OpenShift cluster (eg oc
cluster up). The first thing I've tried was the sidecar example [2] in the
contrib directory but to make it work, I had to tweak the CLI arguments of
the proxy. In practice, I've added the following options:

--redeem-url=https://openshift.default.svc/oauth/token
--validate-url=
https://openshift.default.svc/apis/user.openshift.io/v1/users/~
--openshift-review-url=
https://openshift.default.svc/apis/authorization.openshift.io/v1/subjectaccessreviews

(the last one is only required to use openshift-sar)


Without these changes, the oauth proxy couldn't authenticate clients
because there is a discrepancy between the OAuth endpoints exposed by the
Openshift API and the public certificate (see oauth logs at [3]).


Is that expected? Did I miss some documentation?

Thanks!
Simon

[1] https://github.com/openshift/oauth-proxy
[2]
https://github.com/openshift/oauth-proxy/blob/master/contrib/sidecar.yaml
[3] https://pastebin.com/Fk1h1a7v

___
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: question about openshift origin deployer

[Clayton Coleman]

The deploy command is a sub command in the openshift binary (openshift
infra deploy —help) and makes api calls back to openshift to launch the
pod.  The deployment service account is used by the pod and is granted the
permission to launch hook pods and also to scale the replica set for each
revision of a deployment config.


On Nov 19, 2017, at 12:49 PM, Yu Wei  wrote:

Hi,

How does openshift origin deployer start another container?

I checked docker file about deployer and found stuff as "
/usr/bin/openshift-deploy"?


How is /usr/bin/openshift-deploy implemented? Does it call docker api?

Is "/usr/bin/openshift-deploy" also open sourced? Where could I find it?


Thanks,

Jared, (韦煜）
Software developer
Interested in open source software, big data, Linux

___
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: Openshift router certificate chain

[Clayton Coleman]

Sha1 may not even be in “old” (because I believe it’s now considered
broken.  If you need it, you’ll have to edit the router template with that
cipher.

On Nov 17, 2017, at 7:49 AM, Mateus Caruccio 
wrote:

What is the value of `ROUTER_CIPHERS`?

$ oc -n default env --list dc/router | grep ROUTER_CIPHERS

Maybe you need to set it to `old` in order to support sha1.



--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017

2017-11-17 10:42 GMT-02:00 Marcello Lorenzi :

> Hi Mateus,
> this is the output reported:
>
>
>   # Prevent vulnerability to POODLE attacks
>   ssl-default-bind-options no-sslv3
>
> # The default cipher suite can be selected from the three sets recommended
> by https://wiki.mozilla.org/Security/Server_Side_TLS,
> # or the user can provide one using the ROUTER_CIPHERS environment
> variable.
> # By default when a cipher set is not provided, intermediate is used.
> {{- if eq (env "ROUTER_CIPHERS" "intermediate") "modern" }}
>   # Modern cipher suite (no legacy browser support) from
> https://wiki.mozilla.org/Security/Server_Side_TLS
>   tune.ssl.default-dh-param 2048
>   ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
> ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
> ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
> {{ else }}
>
>   {{- if eq (env "ROUTER_CIPHERS" "intermediate") "intermediate" }}
>   # Intermediate cipher suite (default) from https://wiki.mozilla.org/
> Security/Server_Side_TLS
>   tune.ssl.default-dh-param 2048
>   ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:
> ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:
> ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-
> RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-
> AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-
> SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:
> ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-
> SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-
> AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-
> SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-
> SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
>   {{ else }}
>
> {{- if eq (env "ROUTER_CIPHERS" "intermediate") "old" }}
>
>   # Old cipher suite (maximum compatibility but insecure) from
> https://wiki.mozilla.org/Security/Server_Side_TLS
>   tune.ssl.default-dh-param 1024
>   ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:
> ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:
> ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-
> DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-
> SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:
> ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-
> AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-
> SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-
> SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-
> AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:
> EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:
> AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-
> CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!
> PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP
>
> {{- else }}
>   # user provided list of ciphers (Colon separated list as seen above)
>   # the env default is not used here since we can't get here with empty
> ROUTER_CIPHERS
>   tune.ssl.default-dh-param 2048
>   ssl-default-bind-ciphers {{env "ROUTER_CIPHERS" "ECDHE-ECDSA-CHACHA20-
> POLY1305"}}
> {{- end }}
>   {{- end }}
> {{- end }}
>
> defaults
>   maxconn {{env "ROUTER_MAX_CONNECTIONS" "2"}}
>
>   # Add x-forwarded-for header.
> {{- if ne (env "ROUTER_SYSLOG_ADDRESS" "") "" }}
>   {{- if ne (env "ROUTER_SYSLOG_FORMAT" "") "" }}
>
> Marcello
>
> On Fri, Nov 17, 2017 at 1:36 PM, Mateus Caruccio <
> mateus.caruc...@getupcloud.com> wrote:
>
>> Hey Marcello.
>>
>> Correct me if I'm wrong, but you could look into haproxy's config and set
>> all ciphers you need:
>>
>> $ oc -n default rsh dc/router grep -C 10 ssl-default-bind-ciphers
>> haproxy-config.template
>>
>> There is this env var `ROUTER_CIPHERS` you can choose standard profiles
>> (modern|intermediate|old) or define your own list.
>>
>> Hope this help.
>>
>> Mateus
>>
>>
>> --
>> Mateus Caruccio / Master of Puppets
>> GetupCloud.com
>> We make the infrastructure invisible
>> Gartner Cool Vendor 2017
>>
>> 2017-11-17 10:28 GMT-02:00 Marcello Lorenzi :
>>
>>> Hi All,
>>> we tried to configure a new route on Openshift Origin 3.6 to expose a
>>> pod where the 

Re: OpenShift on AWS - Playbooks

[Clayton Coleman]

The latter is still being actively developed - that will be the future
direction but is not yet ready for genera use.  Our work towards
leveraging node bootstrapping and using pre-baked AMIs is also not
completely finalized, so no expectation of stability on the latter.

> On Oct 26, 2017, at 9:18 AM, Tobias Brunner  wrote:
>
> Hi,
>
> There are at least two different "official" approaches to get OpenShift
> on AWS up and running:
>
> 1.
> https://github.com/openshift/openshift-ansible-contrib/tree/master/reference-architecture/aws-ansible
> 2. https://github.com/openshift/openshift-ansible/tree/master/playbooks/aws
>
> Which one of these two should we chose to get startet and have a
> maintained version? We're commited to contribute, but it's unclear which
> one we should use...
>
> Best,
> Tobias
>
> ___
> 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: OpenShift master keeps consuming lots and memory and swapping

[Clayton Coleman]

No one with 2 nodes and 11 namespaces needs 20GB.

Up to a few hundred pods and ten nodes the openshift processes themselves
shouldn't be using more than a few hundred megs.  If you plan on growing or
haven't upgraded to etcd3 you obviously want to leave some wiggle room, but
even very large clusters don't need that much.

Do keep an eye on etcd memory usage - if it's above 20% of physical you
need to grow your masters immediately.  But you should be nowhere near that
amount of memory at your size.


On Oct 21, 2017, at 7:26 AM, Louis Santillan  wrote:

Firstly, leaving swap enabled is an anti-pattern in general [0] as
OpenShift is then unable to recognize OOM conditions until performance is
thoroughly degraded.  Secondly, we generally recommend to our customers
that they have at least 20GB [1] for Masters.  I've seen many customers go
far past that to suit their comfort.


[0] https://docs.openshift.com/container-platform/3.6/admin_
guide/overcommit.html#disabling-swap-memory
[1] https://docs.openshift.com/container-platform/3.6/
install_config/install/prerequisites.html#production-
level-hardware-requirements


___

LOUIS P. SANTILLAN

SENIOR CONSULTANT, OPENSHIFT, MIDDLEWARE & DEVOPS

Red Hat Consulting, NA US WEST 

lpsan...@gmail.comM: 3236334854

TRIED. TESTED. TRUSTED. 

On Fri, Oct 20, 2017 at 4:54 PM, Joel Pearson  wrote:

> Hi,
>
> I've got a brand new OpenShift cluster running on OpenStack and I'm
> finding that the single master that I have is struggling big time, it seems
> to consume tons of virtual memory and then start swapping and slows right
> down.
>
> It is running with 16GB of memory, 40GB disk and 2 CPUs.
>
> The cluster is fairly idle, so I don't know why the master gets this way.
> Restarting the master solves the problem for a while, for example, I
> restarted it at 10pm last night, and when I checked again this morning it
> was in the same situation.
>
> Would having multiple masters alleviate this problem?
>
> Here is a snapshot of top:
>
> [image: Inline images 1]
>
> Any advice?  I've happy to build the cluster with multiple masters if it
> will help.
>
>
> --
> Kind Regards,
>
> Joel Pearson
> Agile Digital | Senior Software Consultant
>
> Love Your Software™ | ABN 98 106 361 273
>
>
> ___
> 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