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: Best way to get installed?

[Tracy Reed]

On Fri, Apr 13, 2018 at 12:40:04PM PDT, Tim Dudgeon spake thusly:
> For a simple 1 server env you might want to look at 'oc cluster up':
> https://github.com/openshift/origin/blob/master/docs/cluster_up_down.md
> 
> It might be a good way to get you going.

Ah...now we're talking. I saw references to this in minishift also
although I didn't know what it was. I'll give this a try. Thanks!

-- 
Tracy Reed
http://tracyreed.org
Digital signature attached for your safety.


signature.asc
Description: PGP signature
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Best way to get installed?

[Tim Dudgeon]

If you must deploy to GCE then Minishift is not the answer.
It's designed to run on your laptop so that you can test things and get 
up to speed with Openshift.

For that it's ideal.

For a simple 1 server env you might want to look at 'oc cluster up':
https://github.com/openshift/origin/blob/master/docs/cluster_up_down.md

It might be a good way to get you going.


On 13/04/18 20:25, Tracy Reed wrote:

On Fri, Apr 13, 2018 at 12:22:26AM PDT, Tim Dudgeon spake thusly:

Depends on what you are wanting to do.
To get some basic experience with using OpenShift you could try Minishift:

https://docs.openshift.org/latest/minishift/index.html

Thanks. This is so far the only suggestion. However, I have to deploy
this in Google Compute Engine. Minishift requires access to a supported
hypervisor so that it can spinup the VM itself. So unfortunately, this
won't work. I found the minishift github repo where someone had
requested that minishift be able to be provisioned on a pre-existing VM:
https://github.com/minishift/minishift/issues/467 but this is rejected
as they want to have more control over the environment in terms of
storage, cpu, installed OS, etc. So my search continues...

Thanks!



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

Re: Best way to get installed?

[Tracy Reed]

On Fri, Apr 13, 2018 at 12:22:26AM PDT, Tim Dudgeon spake thusly:
> Depends on what you are wanting to do.
> To get some basic experience with using OpenShift you could try Minishift:
> 
> https://docs.openshift.org/latest/minishift/index.html

Thanks. This is so far the only suggestion. However, I have to deploy
this in Google Compute Engine. Minishift requires access to a supported
hypervisor so that it can spinup the VM itself. So unfortunately, this
won't work. I found the minishift github repo where someone had
requested that minishift be able to be provisioned on a pre-existing VM:
https://github.com/minishift/minishift/issues/467 but this is rejected
as they want to have more control over the environment in terms of
storage, cpu, installed OS, etc. So my search continues...

Thanks!

-- 
Tracy Reed
http://tracyreed.org
Digital signature attached for your safety.


signature.asc
Description: PGP signature
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

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

[Alan Christie]

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

Re: CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Tim Dudgeon]

How to best enable these test repos?
I found this ansible property that looks right, but it doesn't help:

openshift_repos_enable_testing=true

When I set these props:

openshift_deployment_type=origin
openshift_release=v3.9

you get this error when running the playbooks/deploy_cluster.yml playbook:

Failure summary:

  1. Hosts:    test39-master
 Play: Determine openshift_version to configure on first master
 Task: openshift_version : fail
 Message:  Package 'origin-3.9*' not found

Other notes for people wanting to try 3.9:
1. you may need to upgrade ansible on the machine you are deploying from
2. the nodes now need the python-ipaddress module to be `yum installed`

On 12/04/18 14:32, Troy Dawson wrote:

We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
corresponding openshift-ansible packages. They have been put in our
testing repos.

DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY

These will not be released until *someone* has tested them.  So
please, someone, anyone, test them, and let us know.

origin 3.9 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
origin-3.9.0-1.el7.git.0.ba7faec
openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7

origin 3.8 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
origin-3.8.0-1.el7.git.0.dd1558c
openshift-ansible-3.8.37-1.git.1.151d57f.el7

origin 3.7 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
origin-3.7.2-1.el7.git.0.cd74924
openshift-ansible-3.7.43-1.git.1.ed51ddd.el7

Once again, test and let us know.  If you don't know who to send it
to, just reply to this email.

Thanks
Paas Sig Group

___
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: [CentOS-devel] CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Rich Megginson]

On 04/13/2018 09:58 AM, Troy Dawson wrote:

On Fri, Apr 13, 2018 at 8:42 AM, Rich Megginson  wrote:

On 04/13/2018 09:39 AM, Troy Dawson wrote:

On Fri, Apr 13, 2018 at 7:58 AM, Rich Megginson 
wrote:

On 04/12/2018 07:32 AM, Troy Dawson wrote:

We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
corresponding openshift-ansible packages. They have been put in our
testing repos.

DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY

These will not be released until *someone* has tested them.  So
please, someone, anyone, test them, and let us know.

origin 3.9 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
origin-3.9.0-1.el7.git.0.ba7faec
openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7

origin 3.8 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
origin-3.8.0-1.el7.git.0.dd1558c
openshift-ansible-3.8.37-1.git.1.151d57f.el7

origin 3.7 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
origin-3.7.2-1.el7.git.0.cd74924
openshift-ansible-3.7.43-1.git.1.ed51ddd.el7

Once again, test and let us know.  If you don't know who to send it
to, just reply to this email.


Having some problems with logging Kibana certificates - issued with
duplicate serial numbers - was

https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
fixed in these 3.9 packages?

  From what I can tell, yes.
Is it acting like it isn't?


It is the same symptom - certificates are being issued with duplicate serial
numbers - but if the fix is in origin 3.9, I'll see if there could possibly
be another cause.


I just double checked the code itself, just in case some later commit
changed things.
The changes that are in
https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
are in origin-3.9.0-1.el7.git.0.ba7faec
So ya, there must be some other cause.


Seems to be working now.  Not sure what happened - probably didn't get 
the latest versions of all of the packages last time I tried.


Sorry for the noise.



Troy



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

Re: [CentOS-devel] CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Troy Dawson]

On Fri, Apr 13, 2018 at 8:42 AM, Rich Megginson  wrote:
> On 04/13/2018 09:39 AM, Troy Dawson wrote:
>>
>> On Fri, Apr 13, 2018 at 7:58 AM, Rich Megginson 
>> wrote:
>>>
>>> On 04/12/2018 07:32 AM, Troy Dawson wrote:

 We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
 corresponding openshift-ansible packages. They have been put in our
 testing repos.

 DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY

 These will not be released until *someone* has tested them.  So
 please, someone, anyone, test them, and let us know.

 origin 3.9 testing
 https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
 origin-3.9.0-1.el7.git.0.ba7faec
 openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7

 origin 3.8 testing
 https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
 origin-3.8.0-1.el7.git.0.dd1558c
 openshift-ansible-3.8.37-1.git.1.151d57f.el7

 origin 3.7 testing
 https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
 origin-3.7.2-1.el7.git.0.cd74924
 openshift-ansible-3.7.43-1.git.1.ed51ddd.el7

 Once again, test and let us know.  If you don't know who to send it
 to, just reply to this email.
>>>
>>>
>>> Having some problems with logging Kibana certificates - issued with
>>> duplicate serial numbers - was
>>>
>>> https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
>>> fixed in these 3.9 packages?
>>
>>  From what I can tell, yes.
>> Is it acting like it isn't?
>
>
> It is the same symptom - certificates are being issued with duplicate serial
> numbers - but if the fix is in origin 3.9, I'll see if there could possibly
> be another cause.
>

I just double checked the code itself, just in case some later commit
changed things.
The changes that are in
https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
are in origin-3.9.0-1.el7.git.0.ba7faec
So ya, there must be some other cause.

Troy

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

Re: [CentOS-devel] CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Rich Megginson]

On 04/13/2018 09:39 AM, Troy Dawson wrote:

On Fri, Apr 13, 2018 at 7:58 AM, Rich Megginson  wrote:

On 04/12/2018 07:32 AM, Troy Dawson wrote:

We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
corresponding openshift-ansible packages. They have been put in our
testing repos.

DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY

These will not be released until *someone* has tested them.  So
please, someone, anyone, test them, and let us know.

origin 3.9 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
origin-3.9.0-1.el7.git.0.ba7faec
openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7

origin 3.8 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
origin-3.8.0-1.el7.git.0.dd1558c
openshift-ansible-3.8.37-1.git.1.151d57f.el7

origin 3.7 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
origin-3.7.2-1.el7.git.0.cd74924
openshift-ansible-3.7.43-1.git.1.ed51ddd.el7

Once again, test and let us know.  If you don't know who to send it
to, just reply to this email.


Having some problems with logging Kibana certificates - issued with
duplicate serial numbers - was
https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
fixed in these 3.9 packages?

 From what I can tell, yes.
Is it acting like it isn't?


It is the same symptom - certificates are being issued with duplicate 
serial numbers - but if the fix is in origin 3.9, I'll see if there 
could possibly be another cause.




Troy



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

Re: [CentOS-devel] CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Troy Dawson]

On Fri, Apr 13, 2018 at 7:58 AM, Rich Megginson  wrote:
> On 04/12/2018 07:32 AM, Troy Dawson wrote:
>>
>> We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
>> corresponding openshift-ansible packages. They have been put in our
>> testing repos.
>>
>> DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY
>>
>> These will not be released until *someone* has tested them.  So
>> please, someone, anyone, test them, and let us know.
>>
>> origin 3.9 testing
>> https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
>> origin-3.9.0-1.el7.git.0.ba7faec
>> openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7
>>
>> origin 3.8 testing
>> https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
>> origin-3.8.0-1.el7.git.0.dd1558c
>> openshift-ansible-3.8.37-1.git.1.151d57f.el7
>>
>> origin 3.7 testing
>> https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
>> origin-3.7.2-1.el7.git.0.cd74924
>> openshift-ansible-3.7.43-1.git.1.ed51ddd.el7
>>
>> Once again, test and let us know.  If you don't know who to send it
>> to, just reply to this email.
>
>
> Having some problems with logging Kibana certificates - issued with
> duplicate serial numbers - was
> https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff
> fixed in these 3.9 packages?

>From what I can tell, yes.
Is it acting like it isn't?

Troy

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

Re: [CentOS-devel] CentOS Origin packages in testing for 3.7, 3.8 and 3.9

[Rich Megginson]

On 04/12/2018 07:32 AM, Troy Dawson wrote:

We have origin packages for 3.7.2, 3.8.0 and 3.9.0.  We also have the
corresponding openshift-ansible packages. They have been put in our
testing repos.

DO NOT USE ORIGIN 3.8.0, IT IS FOR UPGRADE PURPOSES ONLY

These will not be released until *someone* has tested them.  So
please, someone, anyone, test them, and let us know.

origin 3.9 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin39/
origin-3.9.0-1.el7.git.0.ba7faec
openshift-ansible-3.9.0-0.53.0.git.1.af49d87.el7

origin 3.8 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
origin-3.8.0-1.el7.git.0.dd1558c
openshift-ansible-3.8.37-1.git.1.151d57f.el7

origin 3.7 testing
https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin37/
origin-3.7.2-1.el7.git.0.cd74924
openshift-ansible-3.7.43-1.git.1.ed51ddd.el7

Once again, test and let us know.  If you don't know who to send it
to, just reply to this email.


Having some problems with logging Kibana certificates - issued with 
duplicate serial numbers - was 
https://github.com/openshift/origin/pull/18713/commits/95e262011438642410959914c3db9868c57739ff 
fixed in these 3.9 packages?

Thanks
Paas Sig Group
___
CentOS-devel mailing list
centos-de...@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel



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

Re: adding glusterfs to an existing cluster

[Rodrigo Bersa]

Hi Tim,

I normally add the storage=True parameter in the [nodes] section on each
glusterfs node:

[glusterfs]
orn-gluster-storage-001 glusterfs_ip=10.0.0.30 glusterfs_devices='[
"/dev/vdb" ]'
orn-gluster-storage-002 glusterfs_ip=10.0.0.33 glusterfs_devices='[
"/dev/vdb" ]'
orn-gluster-storage-003 glusterfs_ip=10.0.0.7 glusterfs_devices='[
"/dev/vdb" ]'

[nodes]

orn-gluster-storage-001 *storage=True* openshift_hostname=orn-gluster
-storage-001.openstacklocal
orn-gluster-storage-002 *storage=True* openshift_hostname=orn-gluster
-storage-002.openstacklocal
orn-gluster-storage-003 *storage=True* openshift_hostname=orn-gluster
-storage-003.openstacklocal

Kind regards,

Rodrigo Bersa

Cloud Consultant, RHCVA, RHCE

Red Hat Brasil 

rbe...@redhat.comM: +55-11-99557-5841

TRIED. TESTED. TRUSTED. 
Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo *Great Place to Work*.

On Fri, Apr 13, 2018 at 8:28 AM, Tim Dudgeon  wrote:

> I'm having unreliability problems installing a complete cluster, so am
> trying to do this piece by piece.
> First I deploy a basic origin cluster and then I try to deploy glusterfs
> using the playbooks/common/openshift-glusterfs/config.yml playbook (this
> is using v3.7 and the release-3.7 branch of openshift-ansible).
>
> I already have the three gluster nodes as normal nodes in the cluster, and
> now add the gluster sections to the inventory file like this:
>
> [glusterfs]
> orn-gluster-storage-001 glusterfs_ip=10.0.0.30 glusterfs_devices='[
> "/dev/vdb" ]'
> orn-gluster-storage-002 glusterfs_ip=10.0.0.33 glusterfs_devices='[
> "/dev/vdb" ]'
> orn-gluster-storage-003 glusterfs_ip=10.0.0.7 glusterfs_devices='[
> "/dev/vdb" ]'
>
> [nodes]
> 
> orn-gluster-storage-001 openshift_hostname=orn-gluster
> -storage-001.openstacklocal
> orn-gluster-storage-002 openshift_hostname=orn-gluster
> -storage-002.openstacklocal
> orn-gluster-storage-003 openshift_hostname=orn-gluster
> -storage-003.openstacklocal
>
>
> But when I run the playbooks/common/openshift-glusterfs/config.yml
> playbook gluster does not get installed and I see this in the log:
>
> PLAY [Configure GlusterFS] **
> 
> 
> **
> skipping: no hosts matched
>
> What's the right procedure for doing this?
>
> 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: /etc/cni/net.d/ is sometimes empty

[Tim Dudgeon]

Yes, that's exactly the sort of behaviour I'm seeing.
But I also see it when deploying a cluster (the playbooks/byo/config.yml 
playbook) as well as when scaling up.


On one of my (OpenStack) environments it seems to happen on about 50% of 
the nodes!



On 13/04/18 14:51, Rodrigo Bersa wrote:

Hi TIm,

Yes, I've seen this error sometimes, mainly during the Scaleup process.

What I did that apparently solve this issue is to remove the /etc/cni 
directory, and let the installation/scaleup process create it, but I 
don't know the root cause either.


As you said, it happens randomly and don't seem to have a pattern. The 
first time I faced it, I was scaling a cluster and adding four new 
Nodes, and just one presented the error, the other three were added to 
the cluster with no errors.



Best regards,


Rodrigo Bersa

Cloud Consultant, RHCVA, RHCE

Red Hat Brasil 

rbe...@redhat.com  M: +55-11-99557-5841 



  
TRIED. TESTED. TRUSTED. 

Red Hat é reconhecida entre as melhores empresas para trabalhar no 
Brasil pelo *Great Place to Work*.


On Fri, Apr 13, 2018 at 10:10 AM, Tim Dudgeon > wrote:


We've long been encountering a seemingly random problem installing
Origin 3.7 on Centos nodes.
This is manifested in the /etc/cni/net.d/ directory on the node
being empty (it should contain one file named
80-openshift-sdn.conf) and that prevents the origin-node service
from starting, with the key error in the logs (using journalctl)
being something like this:

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

Something is preventing the ansible installer from creating this
file on the nodes (though the real cause maybe upstream of this).

This seems to happen randomly, and with differing frequencies on
different environments. One one environement abotu 50% of the
nodes fail in this way. On others its much less frequent. We
thought this was a problem with our OpenStack environment but we
have now also seen this on AWS so it looks like its a OpenShift
specific problem.

Has anyone else seen this or know what causes it?
It's been a really big impediment to rolling out a cluster.

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

adding glusterfs to an existing cluster

[Tim Dudgeon]

I'm having unreliability problems installing a complete cluster, so am 
trying to do this piece by piece.
First I deploy a basic origin cluster and then I try to deploy glusterfs 
using the playbooks/common/openshift-glusterfs/config.yml playbook (this 
is using v3.7 and the release-3.7 branch of openshift-ansible).


I already have the three gluster nodes as normal nodes in the cluster, 
and now add the gluster sections to the inventory file like this:


[glusterfs]
orn-gluster-storage-001 glusterfs_ip=10.0.0.30 glusterfs_devices='[ 
"/dev/vdb" ]'
orn-gluster-storage-002 glusterfs_ip=10.0.0.33 glusterfs_devices='[ 
"/dev/vdb" ]'
orn-gluster-storage-003 glusterfs_ip=10.0.0.7 glusterfs_devices='[ 
"/dev/vdb" ]'


[nodes]

orn-gluster-storage-001 
openshift_hostname=orn-gluster-storage-001.openstacklocal
orn-gluster-storage-002 
openshift_hostname=orn-gluster-storage-002.openstacklocal
orn-gluster-storage-003 
openshift_hostname=orn-gluster-storage-003.openstacklocal



But when I run the playbooks/common/openshift-glusterfs/config.yml 
playbook gluster does not get installed and I see this in the log:


PLAY [Configure GlusterFS] 


skipping: no hosts matched

What's the right procedure for doing this?

Tim

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

Re: Best way to get installed?

[Tim Dudgeon]

Depends on what you are wanting to do.
To get some basic experience with using OpenShift you could try Minishift:

https://docs.openshift.org/latest/minishift/index.html

Tim


On 12/04/18 22:26, Tracy Reed wrote:

So I've been tasked with setting up an OpenShift cluster for some light
testing. Not prod. I was originally given
https://github.com/RedHatWorkshops/openshiftv3-ops-workshop/blob/master/setting_up_nonha_ocp_cluster.md
as the install guide.

This tutorial takes quite a while to manually setup the 4 nodes (in
GCE), plus storage, etc. and then launches into an hour long ansible
run.  I've been through it 4 times now and each time run into various
odd problems (which I could document for you if necessary).

Is there currently any other simpler and faster way to install
a basic OpenShift setup?

Googling produces a number of other OpenShift tutorials, many of which
now have comments on them about bugs or being out of date etc.

What's the current state of the art in simple openshift install
guides?

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