Containers: Unable to launch vm from horizon if platform horizon was previously used

Bug #1813661 reported by Yang Liu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
Medium
Tyler Smith

Bug Description

Brief Description
-----------------
If user has navigated to platform horizon before, then they will not be able to launch a vm from containerized horizon. Sceenshot attached.

Workaround: clear the cookies of the browser

Severity
--------
Major

Steps to Reproduce
------------------
- Use platform horizon (doesn't have to login)
- Login to containerized horizon (with port 31000)
- Navigate to tenant project > Compute > Instances > Launch Instance

Expected Behavior
------------------
- Launch Instance window pops up properly

Actual Behavior
----------------
- Launch Instance window cannot be fully rendered (see screenshot)
- "Policy check failed." Warning message displayed.

Reproducibility
---------------
Reproducible

System Configuration
--------------------
Any

Branch/Pull Time/Commit
-----------------------
master as of 2019-01-23_20-18-00

Timestamp/Logs
--------------
Easy to reproduce. see screenshot.

Revision history for this message
Yang Liu (yliu12) wrote :
Revision history for this message
Ghada Khalil (gkhalil) wrote :

Marking as release gating; issue related to containerized deployment

Changed in starlingx:
importance: Undecided → Medium
assignee: nobody → Tyler Smith (tyler.smith)
status: New → Triaged
tags: added: stx.2019.05 stx.containers stx.gui
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to stx-gui (f/stein)

Fix proposed to branch: f/stein
Review: https://review.openstack.org/635560

Changed in starlingx:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to stx-config (master)

Fix proposed to branch: master
Review: https://review.openstack.org/635561

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to stx-gui (f/stein)

Reviewed: https://review.openstack.org/635560
Committed: https://git.openstack.org/cgit/openstack/stx-gui/commit/?id=c798c0d493f29c486f53163d9cac8107042efea8
Submitter: Zuul
Branch: f/stein

commit c798c0d493f29c486f53163d9cac8107042efea8
Author: Tyler Smith <email address hidden>
Date: Thu Feb 7 11:08:29 2019 -0500

    Fix horizon VM launch

    Moving the cookie customization to the platform horizon, and
    manually setting the new cookie to be used by our angularJS
    FM client. The change is not needed by the sysinv client since we are
    able to embed the csrf token in the django template, which isn't
    possible with the pure angular FM panels.

    Change-Id: Iceebf7028325256b6793deb296d32e9a9f5fba21
    Signed-off-by: Tyler Smith <email address hidden>
    Closes-Bug: 1813661

tags: added: in-f-stein
Changed in starlingx:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to stx-config (master)

Reviewed: https://review.openstack.org/635561
Committed: https://git.openstack.org/cgit/openstack/stx-config/commit/?id=57de925c109d7b4c02281f70eaab057ca4e4bfe0
Submitter: Zuul
Branch: master

commit 57de925c109d7b4c02281f70eaab057ca4e4bfe0
Author: Tyler Smith <email address hidden>
Date: Thu Feb 7 10:57:59 2019 -0500

    Fix to Horizon VM launching

    This commit removes the cookie name customizations,
    they are being moved into the platform horizon instead

    Change-Id: I2b80dc388f599c3168c45fab7db7cd38cdf96f7e
    Signed-off-by: Tyler Smith <email address hidden>
    Closes-Bug: 1813661
    Depends-On: https://review.openstack.org/#/c/635560/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to stx-config (f/stein)

Fix proposed to branch: f/stein
Review: https://review.openstack.org/636195

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to stx-config (f/stein)
Download full text (9.6 KiB)

Reviewed: https://review.openstack.org/636195
Committed: https://git.openstack.org/cgit/openstack/stx-config/commit/?id=d94e998e455ca0b8b830f314e2292fade5ea7b49
Submitter: Zuul
Branch: f/stein

commit f990ded2116383eb3075fbc9af8e40d0a8173f12
Author: Kristine Bujold <email address hidden>
Date: Mon Feb 11 10:54:12 2019 -0500

    Move cinder static config to Armada manifest

    Review https://review.openstack.org/635952 is missing changes
    required to the manifest.yaml file. This commit fixes that.

    Story: 2003909
    Task: 29419

    Change-Id: I68f79c3b0a155d5687842697bdb7babc6082ac91
    Signed-off-by: Kristine Bujold <email address hidden>

commit b5ef279bd5a93be942e28d98d41712f268854626
Author: Sun Austin <email address hidden>
Date: Mon Feb 11 09:11:11 2019 +0800

    Remove un-necessary exception log

    Closes-Bug: 1814912

    Change-Id: Ic500ca78ace5d95d2356cc06fd332384f99ac28d
    Signed-off-by: Sun Austin <email address hidden>

commit c1385750620d77590d9ca5a6c2a5eb952cf0eeb6
Author: Don Penney <email address hidden>
Date: Fri Feb 8 14:20:04 2019 +0200

    Ceph initialization on AIO is done only in 'controller' manifests

    On AIO deployments puppet is run twice with two different manifests:
    1. 'controller': to configure controller services
    2. 'worker': to configure worker services.

    Ceph is configured when 'controller' manifests are applied, there is
    no need to run them a second time, when 'worker' set is applied.

    Commit adds new puppet classes to encapsulate ceph configuration
    based on node personality and adds a check to not apply it a 2nd
    time on controllers.

    If the ceph manifests are executed a second time then we get into
    a racing issue between SM's process monitoring and 'worker' puppet
    manifests triggering a restart of ceph-mon as part of reconfiguration

    After a reboot on AIO, SM takes control of ceph-mon monitoring
    after 'controller' puppet manifests finish applying. As part of this,
    SM monitors processes death notification and gets the pid from the
    .pid file. And periodically executes '/etc/init.d/ceph status
    mon.controller' for a more advanced monitoring.

    When the 'worker' manifests are executed, they trigger a restart
    of ceph-mon through /etc/init.d/ceph restart that has two steps: 'stop'
    in which ceph-mon is stopped, and 'start' in which it is restarted.

    In the first step, stopping ceph-mon leads to the death of ceph-mon
    process and removal of its PID file. This is promptly detected by
    SM which immediately triggers a start of ceph-mon that creates a
    new pid file. Problem is that ceph-mon was already in a restart,
    and at the end of the 'stop' step the init script cleans up the
    new pid file instead of the old.

    This leads to controllers swacting a couple of times before the system
    gets rid of the rogue process.

    Change-Id: I2a0df3bab716a553e71e322e1515bee2bb2f700d
    Co-authored-by: Ovidiu Poncea <email address hidden>
    Story: 2002844
    Task: 29214
    Signed-off-by: Ovidiu Poncea <ovidiu.poncea@w...

Read more...

Ken Young (kenyis)
tags: added: stx.2.0
removed: stx.2019.05
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.