Contrail-5.0-micro-services-ansible : Kolla provisioning fails with

Bug #1753032 reported by vivekananda shenoy
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
Trunk
Invalid
Critical
Ramprakash R

Bug Description

Hi Ram,

I have already discussed this with Michael Henkel on this, however this is Kolla issue and hence opening this bug.

Please have a look at the failure below, if you need access to the setup drop me an IM on slack.

TASK [mariadb : Waiting for MariaDB service to be ready through VIP] ********************************************************************************************************************
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (6 retries left).
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (5 retries left).
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (4 retries left).
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (3 retries left).
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (2 retries left).
FAILED - RETRYING: Waiting for MariaDB service to be ready through VIP (1 retries left).
fatal: [10.87.65.101]: FAILED! => {"attempts": 6, "changed": false, "cmd": ["docker", "exec", "mariadb", "mysql", "-h", "10.87.65.102", "-P", "3306", "-u", "haproxy", "-e", "show databases;"], "delta": "0:00:00.085902", "end": "2018-03-02 17:38:55.829561", "msg": "non-zero return code", "rc": 1, "start": "2018-03-02 17:38:55.743659", "stderr": "ERROR 2003 (HY000): Can't connect to MySQL server on '10.87.65.102' (111 \"Connection refused\")", "stderr_lines": ["ERROR 2003 (HY000): Can't connect to MySQL server on '10.87.65.102' (111 \"Connection refused\")"], "stdout": "", "stdout_lines": []}
        to retry, use: --limit @/root/contrail-ansible-deployer/playbooks/install_contrail.retry

PLAY RECAP ******************************************************************************************************************************************************************************
10.87.65.10 : ok=43 changed=9 unreachable=0 failed=0
10.87.65.100 : ok=4 changed=0 unreachable=0 failed=0
10.87.65.101 : ok=97 changed=11 unreachable=0 failed=1
10.87.65.102 : ok=43 changed=9 unreachable=0 failed=0
10.87.65.14 : ok=43 changed=9 unreachable=0 failed=0
10.87.65.15 : ok=43 changed=9 unreachable=0 failed=0
10.87.65.17 : ok=43 changed=9 unreachable=0 failed=0
localhost : ok=11 changed=4 unreachable=0 failed=0

[root@5b5-cfm-cc1 contrail-ansible-deployer]#

Changed in juniperopenstack:
assignee: nobody → Ramprakash R (ramprakash)
assignee: Ramprakash R (ramprakash) → Ramprakash R (ramprakashr)
Changed in juniperopenstack:
importance: Undecided → Critical
information type: Proprietary → Public
Changed in juniperopenstack:
assignee: Ramprakash R (ramprakashr) → Ramprakash R (ramprakash)
Jeba Paulaiyan (jebap)
tags: added: ansible
Jeba Paulaiyan (jebap)
tags: added: sanityblocker
Revision history for this message
Abhay Joshi (abhayj) wrote :

Apparently this happened on Vivek's setup. Is this also seen in sanity? Please provide a setup with issue reproduced.

Vineet Gupta (vineetrf)
tags: added: blocker
removed: sanityblocker
Revision history for this message
Ramprakash R (ramprakash) wrote :

The root cause was found to be an issue with /etc/hosts file having invalid entries. Once that was corrected, it was possible to get past this.

Revision history for this message
Pavel Mykhailyk (pavel-mikh) wrote :

Hi
i have same issue even with fixed /etc/hosts
both long / short name pingable but MariaDB not start - what specific format we need for /etc/hosts?

Revision history for this message
Ramprakash R (ramprakash) wrote :

It is best to leave the ansible code to fill up the entries in the /etc/hosts file. The openstack rabbitmq requires the control IP addresses of the nodes to be the first entry in the file (after 127.0.0.1 entry).

Revision history for this message
Sahana Sekhar Palagrahara Chandrashekar (sahanas) wrote : Swift provisioning using loopback

Hello,
           During swift provisioning using loopback, we create three volumes each of size that is specified by the user(default is 5GB). We were wondering if there needs to be a limit set to the size the user can specify.
For ex, if the user gives 50GB as the partition size, three volumes of size 50GB will get created according to the script which may or may not be necessary.
What is the optimal approach that needs to be followed to tackle this?

Thanks,
Sahana Chandrashekar

Revision history for this message
Atul Moghe (moghea) wrote :

Michael and I discussed this, I suggest we should limit it to 10G in UI.
If user enters more than 10G, UI should reject it.

Thanks,
Atul

From: Sahana Chandrashekar <email address hidden>
Date: Monday, August 27, 2018 at 4:46 PM
To: Atul Moghe <email address hidden>, Michael Henkel <email address hidden>, Ramprakash R <email address hidden>, Soumil Kulkarni <email address hidden>, Sarin Kizhakkepurayil <email address hidden>
Subject: Swift provisioning using loopback

Hello,
           During swift provisioning using loopback, we create three volumes each of size that is specified by the user(default is 5GB). We were wondering if there needs to be a limit set to the size the user can specify.
For ex, if the user gives 50GB as the partition size, three volumes of size 50GB will get created according to the script which may or may not be necessary.
What is the optimal approach that needs to be followed to tackle this?

Thanks,
Sahana Chandrashekar

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.