Extending single-master cluster to multi-master

[Daniel Kučera]

Hi,

the docs say that it's not possible to migrate from cluster with one master
to multiple masters.
Is it really so?
Why?
Can it be done manually?

Thanks.
___
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

Unable to get hostPath r/w without privileged: true

[Nick Bartos (nibartos)]

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.


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

Re: Is there a way to specify a node selector to limit nodes evaluated by the cluster capacity analysis tool?

[Avesh Agarwal]

Specify node selector for your worker nodes in the input pod spec.

On Thu, Dec 7, 2017 at 2:41 PM, Cottrell, Ken 
wrote:

> We are testing origin 3.6 cluster capacity analysis tool, currently
> running in a pod as a cronjob. We have 3 worker nodes and 3 infra nodes in
> our cluster, and we are only interested in the number of pods that can be
> scheduled on our worker nodes. Looking at the output of the
> cluster-capacity-pods, we see it is analyzing all 6 nodes by default.
>
> 
> 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

crash looping of registry-console

[Brigman, Larry]

After I have upgraded from 3.6 to 3.7 it looked like things were working.
Yesterday, as I was exploring builds, I got an error where the build container 
could not resolve any external hosts.
The troubleshooting guide recommended that restarting the docker daemon would 
clear this error which it did.
Later, I noticed that registry-console was crash-looping.

What is the process for troubleshooting the registry-console.
What is the process for troubleshooting in general a crash-looping pod?

I did recover things but the hard way, I rebooted everything.  When I move this 
to production, that won't be the first option.

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

Re: Permissions problem mounting file from ConfigMap

[Graham Dumpleton]

I don't know. But should be within a minute or so.

Do note that this refresh ability does depend on it being enabled in the 
cluster master configuration. It should be, although have seen where cluster 
was upgraded from 3.5 to 3.6, the setting somehow got lost and had to be fixed 
after the fact when issue was found that refresh wasn't occuring.

Graham

> On 13 Dec 2017, at 9:33 pm, Joel Pearson  
> wrote:
> 
> Oh, I didn't realise configmaps got updated without a Pod restart.  How long 
> does it take to update?  I see in 
> (https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically
>  
> )
>  it says the kubelet sync period + ttl.  What are the OpenShift defaults for 
> that?
> 
> On Wed, Dec 13, 2017 at 8:41 PM Graham Dumpleton  > wrote:
> If you copy it rather than symlink, you will loose the ability that an update 
> to the configmap will be reflected automatically inside of the container 
> after a short period. If the file was something that was rescanned by the 
> application, this allows changes to be pushed into a container without 
> needing to do a restart. If you only read the file once on start up, then 
> copying would be fine.
> 
> Graham
> 
> 
> 
>> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon > > wrote:
>> 
>> Graham,
>> 
>> Thanks for your help on this.
>> I had managed to work around the problem in a way similar to how you 
>> described (but copying not symlinking). Not nice, but it works! 
>> 
>> On 12/12/17 21:10, Graham Dumpleton wrote:
>>> A belated update on this.
>>> 
>>> The problem with using subPath is due to a SELinux issue in the kernel.
>>> 
>>> There is an issue about it at:
>>> 
>>> https://github.com/openshift/origin/issues/16951 
>>> 
>>> 
>>> Whether you see it will depend on how SELinux is setup I guess.
>>> 
>>> The only work around would be to mount it as a directory '..data' in the 
>>> target directory, and then you create a symlink from startup run script in 
>>> your source code to symlink the file in the '..data' directory into the 
>>> parent. Know of no other solution at this point.
>>> 
>>> Graham
>>> 
 On 9 Dec 2017, at 8:36 pm, Tim Dudgeon > wrote:
 
 If you mount onto a new directory you get the same problem.
 It only seems to happen when specifying a subPath as follows:
 
 - mountPath: 
 /usr/local/tomcat/webapps/portal/META-INF/context.xml
   name: squonk-sso-config
   subPath: context.xml
   readOnly: true
 
 If the whole configMap is mounted to a directory the contents are readable.
 
 And as mentioned already, if you do this in Minishift it works fine.
 
 
 On 09/12/17 02:16, Graham Dumpleton wrote:
> The permissions is correct. It is shown as decimal, not the octal you are 
> setting it with.
> 
 '%o' % 420
> '644'
> 
> What happens when you mount the configmap onto a directory separate from 
> anything else?
> 
> Graham
> 
>> On 9 Dec 2017, at 4:02 am, Tim Dudgeon > > wrote:
>> 
>> More on this.
>> 
>> I find when I look a the deployment yaml that the volume ends up looking 
>> like this:
>> 
>>   volumes:
>> - configMap:
>> defaultMode: 420
>> name: squonk-sso-config
>>   name: squonk-sso-config
>> 
>> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
>> default for defaultMode is 0644.
>> 
>> Even when I specify defaultMode: 0644 in the template it ends up being 
>> 420.
>> 
>> Any idea what's going on?
>> 
>> 
>> On 08/12/17 16:44, Tim Dudgeon wrote:
>>> Hi All,
>>> 
>>> I'm having a problem mounting a file from a ConfigMap when running on 
>>> an Openshift origin environment, but when doing the same on Minishift 
>>> it works fine.
>>> 
>>> I'm mounting the context.xml file from the ConfigMap into the container 
>>> like this:
>>> 
>>>   spec:
>>> containers:
>>> - image: ...
>>>   ...
>>>   volumeMounts:
>>> - mountPath: 
>>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>>   name: my-configmap-vol
>>>   subPath: context.xml
>>>   readOnly: true
>>> volumes:
>>>   - name: my-configmap-vol
>>> configMap:
>>>   

Re: Permissions problem mounting file from ConfigMap

[Joel Pearson]

Oh, I didn't realise configmaps got updated without a Pod restart.  How
long does it take to update?  I see in (
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically)
it says the kubelet sync period + ttl.  What are the OpenShift defaults for
that?

On Wed, Dec 13, 2017 at 8:41 PM Graham Dumpleton 
wrote:

> If you copy it rather than symlink, you will loose the ability that an
> update to the configmap will be reflected automatically inside of the
> container after a short period. If the file was something that was
> rescanned by the application, this allows changes to be pushed into a
> container without needing to do a restart. If you only read the file once
> on start up, then copying would be fine.
>
> Graham
>
>
>
> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon  wrote:
>
> Graham,
>
> Thanks for your help on this.
> I had managed to work around the problem in a way similar to how you
> described (but copying not symlinking). Not nice, but it works!
>
> On 12/12/17 21:10, Graham Dumpleton wrote:
>
> A belated update on this.
>
> The problem with using subPath is due to a SELinux issue in the kernel.
>
> There is an issue about it at:
>
> https://github.com/openshift/origin/issues/16951
>
> Whether you see it will depend on how SELinux is setup I guess.
>
> The only work around would be to mount it as a directory '..data' in the
> target directory, and then you create a symlink from startup run script in
> your source code to symlink the file in the '..data' directory into the
> parent. Know of no other solution at this point.
>
> Graham
>
> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon  wrote:
>
> If you mount onto a new directory you get the same problem.
> It only seems to happen when specifying a subPath as follows:
>
> - mountPath:
> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>   name: squonk-sso-config
>   subPath: context.xml
>   readOnly: true
>
> If the whole configMap is mounted to a directory the contents are readable.
>
> And as mentioned already, if you do this in Minishift it works fine.
>
>
> On 09/12/17 02:16, Graham Dumpleton wrote:
>
> The permissions is correct. It is shown as decimal, not the octal you are
> setting it with.
>
> '%o' % 420
>
> '644'
>
> What happens when you mount the configmap onto a directory separate from
> anything else?
>
> Graham
>
> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  wrote:
>
> More on this.
>
> I find when I look a the deployment yaml that the volume ends up looking
> like this:
>
>   volumes:
> - configMap:
> defaultMode: 420
> name: squonk-sso-config
>   name: squonk-sso-config
>
> This is despite `oc explain pod.spec.volumes.configMap` stating that the
> default for defaultMode is 0644.
>
> Even when I specify defaultMode: 0644 in the template it ends up being 420.
>
> Any idea what's going on?
>
>
> On 08/12/17 16:44, Tim Dudgeon wrote:
>
> Hi All,
>
> I'm having a problem mounting a file from a ConfigMap when running on an
> Openshift origin environment, but when doing the same on Minishift it works
> fine.
>
> I'm mounting the context.xml file from the ConfigMap into the container
> like this:
>
>   spec:
> containers:
> - image: ...
>   ...
>   volumeMounts:
> - mountPath:
> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>   name: my-configmap-vol
>   subPath: context.xml
>   readOnly: true
> volumes:
>   - name: my-configmap-vol
> configMap:
>   name: squonk-sso-config
>
> Within the container the file is there but has permissions problems:
>
> # ls -l
> ls: cannot access 'context.xml': Permission denied
> total 4
> -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
> -?? ? ??  ?? context.xml
>
> Any idea what's the problem?
>
> ___
> 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: Permissions problem mounting file from ConfigMap

[Graham Dumpleton]

If you copy it rather than symlink, you will loose the ability that an update 
to the configmap will be reflected automatically inside of the container after 
a short period. If the file was something that was rescanned by the 
application, this allows changes to be pushed into a container without needing 
to do a restart. If you only read the file once on start up, then copying would 
be fine.

Graham


> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon  wrote:
> 
> Graham,
> 
> Thanks for your help on this.
> I had managed to work around the problem in a way similar to how you 
> described (but copying not symlinking). Not nice, but it works! 
> 
> On 12/12/17 21:10, Graham Dumpleton wrote:
>> A belated update on this.
>> 
>> The problem with using subPath is due to a SELinux issue in the kernel.
>> 
>> There is an issue about it at:
>> 
>> https://github.com/openshift/origin/issues/16951 
>> 
>> 
>> Whether you see it will depend on how SELinux is setup I guess.
>> 
>> The only work around would be to mount it as a directory '..data' in the 
>> target directory, and then you create a symlink from startup run script in 
>> your source code to symlink the file in the '..data' directory into the 
>> parent. Know of no other solution at this point.
>> 
>> Graham
>> 
>>> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon >> > wrote:
>>> 
>>> If you mount onto a new directory you get the same problem.
>>> It only seems to happen when specifying a subPath as follows:
>>> 
>>> - mountPath: 
>>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>>   name: squonk-sso-config
>>>   subPath: context.xml
>>>   readOnly: true
>>> 
>>> If the whole configMap is mounted to a directory the contents are readable.
>>> 
>>> And as mentioned already, if you do this in Minishift it works fine.
>>> 
>>> 
>>> On 09/12/17 02:16, Graham Dumpleton wrote:
 The permissions is correct. It is shown as decimal, not the octal you are 
 setting it with.
 
>>> '%o' % 420
 '644'
 
 What happens when you mount the configmap onto a directory separate from 
 anything else?
 
 Graham
 
> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  > wrote:
> 
> More on this.
> 
> I find when I look a the deployment yaml that the volume ends up looking 
> like this:
> 
>   volumes:
> - configMap:
> defaultMode: 420
> name: squonk-sso-config
>   name: squonk-sso-config
> 
> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
> default for defaultMode is 0644.
> 
> Even when I specify defaultMode: 0644 in the template it ends up being 
> 420.
> 
> Any idea what's going on?
> 
> 
> On 08/12/17 16:44, Tim Dudgeon wrote:
>> Hi All,
>> 
>> I'm having a problem mounting a file from a ConfigMap when running on an 
>> Openshift origin environment, but when doing the same on Minishift it 
>> works fine.
>> 
>> I'm mounting the context.xml file from the ConfigMap into the container 
>> like this:
>> 
>>   spec:
>> containers:
>> - image: ...
>>   ...
>>   volumeMounts:
>> - mountPath: 
>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>   name: my-configmap-vol
>>   subPath: context.xml
>>   readOnly: true
>> volumes:
>>   - name: my-configmap-vol
>> configMap:
>>   name: squonk-sso-config
>> 
>> Within the container the file is there but has permissions problems:
>> 
>> # ls -l
>> ls: cannot access 'context.xml': Permission denied
>> total 4
>> -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
>> -?? ? ??  ?? context.xml
>> 
>> Any idea what's the problem?
>> 
> ___
> 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: Permissions problem mounting file from ConfigMap

[Tim Dudgeon]

Graham,

Thanks for your help on this.
I had managed to work around the problem in a way similar to how you 
described (but copying not symlinking). Not nice, but it works!



On 12/12/17 21:10, Graham Dumpleton wrote:

A belated update on this.

The problem with using subPath is due to a SELinux issue in the kernel.

There is an issue about it at:

https://github.com/openshift/origin/issues/16951

Whether you see it will depend on how SELinux is setup I guess.

The only work around would be to mount it as a directory '..data' in 
the target directory, and then you create a symlink from startup run 
script in your source code to symlink the file in the '..data' 
directory into the parent. Know of no other solution at this point.


Graham

On 9 Dec 2017, at 8:36 pm, Tim Dudgeon > wrote:


If you mount onto a new directory you get the same problem.
It only seems to happen when specifying a subPath as follows:

    - mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: squonk-sso-config
  subPath: context.xml
  readOnly: true

If the whole configMap is mounted to a directory the contents are 
readable.


And as mentioned already, if you do this in Minishift it works fine.


On 09/12/17 02:16, Graham Dumpleton wrote:
The permissions is correct. It is shown as decimal, not the octal 
you are setting it with.



'%o' % 420

'644'

What happens when you mount the configmap onto a directory separate 
from anything else?


Graham

On 9 Dec 2017, at 4:02 am, Tim Dudgeon > wrote:


More on this.

I find when I look a the deployment yaml that the volume ends up 
looking like this:


  volumes:
- configMap:
defaultMode: 420
name: squonk-sso-config
  name: squonk-sso-config

This is despite `oc explain pod.spec.volumes.configMap` stating 
that the default for defaultMode is 0644.


Even when I specify defaultMode: 0644 in the template it ends up 
being 420.


Any idea what's going on?


On 08/12/17 16:44, Tim Dudgeon wrote:

Hi All,

I'm having a problem mounting a file from a ConfigMap when running 
on an Openshift origin environment, but when doing the same on 
Minishift it works fine.


I'm mounting the context.xml file from the ConfigMap into the 
container like this:


  spec:
containers:
- image: ...
  ...
  volumeMounts:
- mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: my-configmap-vol
  subPath: context.xml
  readOnly: true
volumes:
  - name: my-configmap-vol
configMap:
  name: squonk-sso-config

Within the container the file is there but has permissions problems:

# ls -l
ls: cannot access 'context.xml': Permission denied
total 4
-rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
-?? ? ?    ?  ?    ? context.xml

Any idea what's the problem?


___
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