Mirantis OpenStack

OSTF Sahara test on cluste creation failed with Conflict: resources.master.resources[0].resources.inst: Port 24a35b69-3e13-49ec-821b-74b8e43d8577 is still in use. (HTTP 409)

Bug #1551251 reported by Andrey Sledzinskiy on 2016-02-29

This bug report is a duplicate of: Bug #1551281: Instance creation on Sahara cluster failed with Error: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied. Edit Remove

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Mirantis OpenStack	Confirmed	High	Sergey Kraynev	Mirantis OpenStack 9.0

Bug Description

iso - 9.0-46

Steps:
1. Create and deploy next cluster - Neutron tun, default storages, Sahara, 3 controllers, 1 compute
2. After deployment import sahara image
3. Open Health Check tab
4. Run Sahara test for launching a simple Vanilla2 cluster

Actual result - test failed

from ostf log from response of failed sahara cluster:

"status_description": "Creating cluster failed for the following reason(s): Heat stack failed with status Resource CREATE failed: Conflict: resources.master.resources[0].resources.inst: Port 24a35b69-3e13-49ec-821b-74b8e43d8577 is still in use. (HTTP 409) (Request-ID: req-0a4be1d9-15c3-41cb-a2d7-d4071efd0512)\nError ID: 0af3bc2c-bad9-4559-b8c3-9bd02292002c", "hadoop_version": "2.7.1", "info": {}, "cluster_template_id": "425cbb14-9039-489b-952d-a7b7070aa48b"

fuel version - http://paste.openstack.org/show/488532/

Tags:

Revision history for this message

Andrey Sledzinskiy (asledzinskiy) wrote on 2016-02-29:

fail_error_deploy_sahara_ha_tun-fuel-snapshot-2016-02-29_00-36-06.tar.xz Edit (38.2 MiB, application/octet-stream)

Revision history for this message

Evgeny Sikachev (esikachev) wrote on 2016-02-29:

Looks like Heat cannot create port. This bug was reproduced on 8.0 release, once

Changed in fuel:
assignee:	MOS QA Team (mos-qa) → MOS Heat (mos-heat)

Timur Nurlygayanov (tnurlygayanov) on 2016-02-29

tags:	added: area-mos heat
affects:	fuel → mos
Changed in mos:
milestone:	9.0 → none

Nastya Urlapova (aurlapova) on 2016-03-01

Changed in mos:
milestone:	none → 9.0
status:	New → Confirmed

Evgeny Sikachev (esikachev) on 2016-03-02

tags:

added: area-heat
removed: heat

Sergey Kraynev (skraynev) on 2016-03-02

Changed in mos:
assignee:	MOS Heat (mos-heat) → Sergey Kraynev (skraynev)

Revision history for this message

Sergey Kraynev (skraynev) wrote on 2016-03-04:

In nova-api logs we can see, that information for both ports were updated and device id was set:
f0492c8a-3b22-4232-876d-19f2a79624f5 and dc00a5aa-634c-456e-a507-9a9943924e8c.

Also in nova conductor logs both these VMs failed with traceback:

ERROR nova.scheduler.utils [req-12ce13a4-f471-4d71-af12-a0dd2121fb7b 848dac061b1946db83b46cfbbc983305 001a566078494a3aa5ae3cc430f9d93f - - -] [instance: f0492c8a-3b22-4232-876d-19f2a79624f5] Error from last host: node-3.test.domain.local (node node-3.test.domain.local): [u'Traceback (most recent call last):\n', u' File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1920, in _do_build_and_run_instance\n filter_properties)\n', u' File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2086, in _build_and_run_instance\n instance_uuid=instance.uuid, reason=six.text_type(e))\n', u'RescheduledException: Build of instance f0492c8a-3b22-4232-876d-19f2a79624f5 was re-scheduled: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied\nfailed to initialize KVM: Permission denied\n\n']