Fuel-QA: OSTF tests fails after replace cluster repositories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fuel for OpenStack |
Confirmed
|
High
|
Fuel QA Team | ||
Mitaka |
Confirmed
|
High
|
Fuel QA Team |
Bug Description
Detailed bug description:
Found on CI:
https:/
Test: Deploy cluster with multiple services using local mirror
Test Group: deploy_
Steps to reproduce:
1. Revert snapshot 'prepare_slaves_5' with default set of mirrors
2. Run 'fuel-mirror' to create mirror repositories
3. Create cluster with many components to check as many
packages in local mirrors have correct dependencies
4. Run 'fuel-mirror' to replace cluster repositories
with local mirrors
5. Check that repositories are changed
6. Deploy cluster
7. Check running services with OSTF
Expected results:
All OSTF tests are finished without errors
Actual result:
Failed 2 OSTF tests with error 'Authorization failure. Please provide the valid credentials for your OpenStack environment, and reattempt.'
- Launch instance, create snapshot, launch instance from snapshot
- Create user and authenticate with it
Description of the environment:
9.1 snapshot #81
FUEL_QA_
UBUNTU_
CENTOS_
MOS_UBUNTU_
MOS_CENTOS_
MOS_CENTOS_
MOS_CENTOS_
MOS_CENTOS_
MOS_CENTOS_
MOS_CENTOS_
https:/
tags: | added: swarm-fail |
tags: | added: area-python |
Changed in fuel: | |
milestone: | none → 9.1 |
assignee: | nobody → Fuel Sustaining (fuel-sustaining-team) |
importance: | Undecided → High |
status: | New → Confirmed |
tags: | added: 9.1-proposed |
Changed in fuel: | |
milestone: | 9.1 → 10.0 |
Changed in fuel: | |
assignee: | Fuel Sustaining (fuel-sustaining-team) → Georgy Kibardin (gkibardin) |
Keystone has returned 500 due to mysql:
key_buffer_ size=16777216 size=131072 connections= 0 size)*max_ threads = 76505 K bytes of memory
read_buffer_
max_used_
max_threads=151
thread_count=1
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f89667b5770 mysqld( my_print_ stacktrace+ 0x2c)[0x7f89648 48b7c] mysqld( handle_ fatal_signal+ 0x3c2)[ 0x7f89645995c2] 64-linux- gnu/libpthread. so.0(+0x10340) [0x7f896328e340 ] mysqld( thd_get_ ha_data+ 0xc)[0x7f89645e 654c] mysqld( _Z20thd_ binlog_ trx_resetP3THD+ 0x2e)[0x7f89647 f379e] mysqld( _Z17wsrep_ post_commitP3TH Db+0xcc) [0x7f89646d332c ] mysqld( _Z12trans_ commitP3THD+ 0x6f)[0x7f89646 b9dcf] mysqld( _Z21mysql_ execute_ commandP3THD+ 0x38d1) [0x7f8964627851 ] mysqld( _Z11mysql_ parseP3THDPcjP1 2Parser_ state+0x3c8) [0x7f896462b9d8 ] mysqld( +0x508c24) [0x7f896462bc24 ] mysqld( _Z19do_ handle_ bootstrapP3THD+ 0x111)[ 0x7f896462bff1] mysqld( +0x509060) [0x7f896462c060 ] 64-linux- gnu/libpthread. so.0(+0x8182) [0x7f8963286182 ] 64-linux- gnu/libc. so.6(clone+ 0x6d)[0x7f89629 a947d]
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f896400ee88 thread_stack 0x30000
/usr/sbin/
/usr/sbin/
/lib/x86_
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib/x86_
/lib/x86_
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f893c0009f0): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED