StarlingX R2 duplex: VM on controller-0 NOT re-spawned on controller-1 after rebooting controller-0.

Bug #1852719 reported by Akshay
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Won't Fix
Low
Unassigned

Bug Description

Brief Description
-----------------
Setup: I have deployed Bare Metal StarlingX R2 duplex mode. While testing HA, I tested a case in which I have spawned 2 VMs from horizon together on IPv6 flat and IPv6 vlan networks. One gets spawned on controller-0 and other on controller-1. Both VM gets IP assigned on each network and they are able to ping each other.

Test Case: Now I switched off the controller-0 (active node) and the VM on controller-0 gets into re-building state.

Issue 1: But the VM remains in rebuilding state through out the rebooting time taken by controller-0 (Active node) and after successful bootup of Active node, the VM comes up on controller-0 (Active node) only.

Issue 2: Also if controller-0 is switched off, the VM on controller-0 goes for re-building itself but after some time falls into ERROR state as it was trying to re-build on controller-0 which is not available now.

I tried this case many times but out of 10 both the issues were faced near about 1-2 times only.
Please guide me to solve this inconsistent issue.

Severity
--------

Critical

Steps to Reproduce
------------------
1. Deploy Bare Metal StarlingX R2 duplex mode.
2. Spawn 2 VMs together on IPv6 flat and IPv6 vlan from horizon.
3. Switch off the controller-0 (active node).
4. Check the rebuilding process of VM on controller-0.

Expected Behavior
------------------
VM should rebuild itself on other available node.

Actual Behavior
----------------
VM rebuild itself on same node which is rebooted/switched off.

Reproducibility
---------------
NOT exactly, but facing it 1-2 times out of 10.

System Configuration
--------------------
Two node system

Last Pass
---------
NO

Ghada Khalil (gkhalil)
tags: added: stx.distro.openstack
Revision history for this message
Ghada Khalil (gkhalil) wrote :

This issue was reported for stx.2.0. There are no logs for further investigation. Since then, stx.3.0 has become available and stx.4.0 is soon to be released (July 2020).

Suggest trying one of the newer releases and opening a new LP with more data (collect logs) if the issue persists.

Changed in starlingx:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Ramaswamy Subramanian (rsubrama) wrote :

No progress on this bug for more than 2 years. Candidate for closure.

If there is no update, this issue is targeted to be closed as 'Won't Fix' in 2 weeks.

Revision history for this message
Ramaswamy Subramanian (rsubrama) wrote :

Changing the status to 'Won't Fix' as there is no activity.

Changed in starlingx:
status: Triaged → Won't Fix
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.