fuel-qa unable to resume deployment of env destroyed just before empty snapshot creation

Bug #1580801 reported by Sergey Yudin on 2016-05-11
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fuel QA Team

Bug Description

Steps to reproduce:
1) Start deployment of any TG with fuel-qa
2) Kill deployment in the middle of provisioning of fuel master
3) Start deployment again with the same environment name

Actual result:
Fuel master will hung with message "booting to hard disk"

Expected behavior:
Fuel master will be booted from iso again and will start provision

Sergey Yudin (tsipa740) on 2016-05-11
summary: - fuel-qa unable to resume deployment destroyed just before empty snapshot
- creation
+ fuel-qa unable to resume deployment of env destroyed just before empty
+ snapshot creation
Artem Panchenko (apanchenko-8) wrote :

Tests are using fuel-devops which configures the following devices boot order:


At first VM boot HDD is empty, so it boots from iso and Fuel installation is being started. When you kill deployment during CentOS provisioning on master node, partition table is created and something is already written to MBR (most probably boot flag is set), but GRUB isn't installed. So during next boot (new test run) master node VM tries to boot from HDD and hangs (I believe it's a bug in BIOS used by qemu).

The easiest way to workaround this issue is set KEEP_BEFORE=no [0] or manually erase environment before restarting tests.

[0] https://github.com/openstack/fuel-qa/blob/eaea19b42fcfb84e8936187852f0355ebda88a17/utils/jenkins/system_tests.sh#L183-L184

Changed in fuel:
milestone: none → 10.0
importance: Undecided → Wishlist
assignee: nobody → Fuel QA Team (fuel-qa)
status: New → Confirmed
Sergey Yudin (tsipa740) wrote :

We using 'build only current patchset' in jenkins and if someone upload a patchset when fuel master being installed jenkins will cancel build and will start another one, so next build started on environment which was canceled before will hung and fail.

Dmitry Belyaninov (dbelyaninov) wrote :

It seems that more prefferable way is using different envs names according to patchset id. Like "env_name_for_ps_X".
In this case there is no affect from old env.
Cleaner will destroy and erase both envs.

Changed in fuel:
assignee: Fuel QA Team (fuel-qa) → Fuel CI (fuel-ci)
Roman Vyalov (r0mikiam) wrote :

please attach the jenkins job/ server name with this problem .
As i understand the problem not related to our mos-ci

Changed in fuel:
status: Confirmed → Incomplete
Sergey Yudin (tsipa740) wrote :

I don't really understood how the fact it didn't affect your environment means that report is incomplete. Could you please describe what exactly is incomplete?

Roman Vyalov (r0mikiam) wrote :

according to the comment #3 the problem may be related to mos infra. if yes , please provide the jenkins jobs or server name. if the problem related to local env or other ci's , then i will move the bug back to fuel-qa

Sergey Yudin (tsipa740) wrote :

The problem is not related to mos infra. The problem somewhere between FQA and DOS.

Roman Vyalov (r0mikiam) on 2017-03-16
Changed in fuel:
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Roman Vyalov (r0mikiam) wrote :

moved back to fuel-qa team.

Changed in fuel:
assignee: Fuel CI (fuel-ci) → Fuel QA Team (fuel-qa)
status: Incomplete → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers