Apply of stx-openstack application fails if unknown image ever specified

Bug #1821344 reported by Bart Wensley
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
High
Angie Wang

Bug Description

Title
-----
Apply of stx-openstack application fails if incorrect image ever specified

Brief Description
-----------------
If the user ever specifies an incorrect image name in helm chart override, the stx-openstack application apply will fail (expected). However, from that point on, apply will always fail - there is no way to recover from this issue without editing system files by hand.

The problem is caused because the incorrect image is added to the download_images section of the /opt/platform/armada/19.01/stx-openstack-images.yaml file. The image is never removed from this file, even if the override is deleted.

Severity
--------
Critical: System/Feature is not usable after the defect

Steps to Reproduce
------------------
Specify an image that does not exist in a helm chart override. For example:
system helm-override-update neutron openstack --set images.tags.neutron_l3=this_image_does_not_exist

Apply the stx-openstack application (this will fail as expected):
system application-apply stx-openstack

Delete the override:
system helm-override-delete neutron openstack

Apply the stx-openstack application (this will fail when trying to download the image):
system application-apply stx-openstack

Expected Behavior
------------------
After the override is deleted, the stx-openstack application apply should be successful.

Actual Behavior
----------------
The stx-openstack application can no longer be applied.

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

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

Branch/Pull Time/Commit
-----------------------
SW_VERSION="19.01"
BUILD_TARGET="Unknown"
BUILD_TYPE="Informal"
BUILD_ID="n/a"

JOB="n/a"
BUILD_BY="bwensley"
BUILD_NUMBER="n/a"
BUILD_HOST="yow-bwensley-lx-vm2"
BUILD_DATE="2019-03-20 08:05:38 -0500"

BUILD_DIR="/"
WRS_SRC_DIR="/localdisk/designer/bwensley/starlingx-0/cgcs-root"
WRS_GIT_BRANCH="HEAD"
CGCS_SRC_DIR="/localdisk/designer/bwensley/starlingx-0/cgcs-root/stx"
CGCS_GIT_BRANCH="HEAD"

Timestamp/Logs
--------------
Logs are not required as the problem is easy to reproduce.

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

Marking as release gating; system cannot be recovered from this error without a manual workaround.

tags: added: stx.2019.05 stx.containers
Changed in starlingx:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Angie Wang (angiewang)
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/649643

Changed in starlingx:
status: Triaged → In Progress
Ghada Khalil (gkhalil)
tags: added: stx.2.0
removed: stx.2019.05
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to stx-config (master)

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

commit d1536ac9dfbb0d17a6fd30d61f76deb0dee57594
Author: Angie Wang <email address hidden>
Date: Wed Mar 27 10:10:32 2019 -0400

    Fix the image download issue if unknown image ever specified

    We have a yaml file which has a section "download_images" stores
    the required images. The required images list will be regenerated
    when applying application. The current logic is to extend the stored
    image list with the newly generated image list which causes the
    application apply to always fail if the user ever specifies an
    unknown image. The extend should be removed.

    Change-Id: I6ee031c7f866ab213e2ef8204c1f829567dcb376
    Closes-Bug: 1821344
    Signed-off-by: Angie Wang <email address hidden>

Changed in starlingx:
status: In Progress → Fix Released
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.