--stack-only not more working on Master tripleoclient

Bug #1887811 reported by Cédric Jeanneret
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
Medium
Rabi Mishra

Bug Description

Hello,

the "--stack-only" option doesn't stop the deploy once the stack is created - it goes all the way to the deploy itself and all.

Versions:
python3-tripleoclient-13.4.0-0.20200713220947.2c6dc2f.el8.noarch
python3-tripleo-common-12.5.0-0.20200710115415.1bab8cc.el8.noarch

Sample command:
#!/bin/bash
# This file is managed by ansible
set -xeo pipefail

export DEPLOY_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
export DEPLOY_STACK=overcloud-0
export DEPLOY_TIMEOUT_ARG=90
export DEPLOY_NETWORKS_FILE=/home/stack/oc0-network-data.yaml
source /home/stack/stackrc; openstack overcloud deploy \
 --templates $DEPLOY_TEMPLATES \
 --stack $DEPLOY_STACK \
 --stack-only \
 --timeout $DEPLOY_TIMEOUT_ARG \
 -e /usr/share/openstack-tripleo-heat-templates/environments/net-multiple-nics.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
 -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
 -e /home/stack/ipa.yaml \
 -e /home/stack/containers-prepare-parameter.yaml \
 -e /home/stack/generated-container-prepare.yaml \
 -e /home/stack/domain.yaml \
 --environment-directory /home/stack/overcloud-0-yml \
 -n $DEPLOY_NETWORKS_FILE 2>&1 | tee oc0-deploy.log

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-tripleoclient (master)

Fix proposed to branch: master
Review: https://review.opendev.org/741482

Changed in tripleo:
assignee: nobody → Rabi Mishra (rabi)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-tripleoclient (master)

Reviewed: https://review.opendev.org/741482
Committed: https://git.openstack.org/cgit/openstack/python-tripleoclient/commit/?id=5805ee4dbedac673268c6c3cf2ef616b887a1a5d
Submitter: Zuul
Branch: master

commit 5805ee4dbedac673268c6c3cf2ef616b887a1a5d
Author: Rabi Mishra <email address hidden>
Date: Thu Jul 16 20:49:38 2020 +0530

    Don't run config-download for --stack-only

    We now seem to run config-download irrespective of the
    --stack-only flag. This moves the config-download
    related code within the if block.

    Change-Id: I0185cb54ac32e1ac8558d22ba4c735a02e80a470
    Closes-Bug: #1887811

Changed in tripleo:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-tripleoclient (stable/ussuri)

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/741941

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-tripleoclient (stable/ussuri)

Reviewed: https://review.opendev.org/741941
Committed: https://git.openstack.org/cgit/openstack/python-tripleoclient/commit/?id=a29f42a531ba1110b18063b859fe348b1c9b159c
Submitter: Zuul
Branch: stable/ussuri

commit a29f42a531ba1110b18063b859fe348b1c9b159c
Author: Emilien Macchi <email address hidden>
Date: Tue Jun 16 10:34:44 2020 -0400

    [ussuri] squash for overcloud_deploy raise changes

    This squash allows to backport a feature without a regression that was
    introduced. It has 2 commits:

    1) overcloud_deploy: raise at the end if Ansible Runner had exception

    In the context of MaxFailPercentage, if a node (e.g. one of 100
    computes) has any fatal error during an Ansible play and we tolerate
    some percentage of failure; we want to raise the error but at the very
    end of the deployment.

    So this patch puts the following actions in a "finally" block so they
    always execute:

    * Create overcloudrc
    * Sets the right permissions to the clouds.yaml
    * Execute _deploy_postconfig
    * Print infos like Keystone entpoint, Horizon URL, RC file location
      and deploy message (saying if there is an error or not)

    And at the very end we raise the actual AnsibleRunner trace if the
    deployment failed.

    So even if a node failed and we tolerate it, we'll still finish the
    deployment until the end, but for UX purpose we want to raise it at the
    very end.
    Note that when it fails and it's tolerated, Ansible prints the node as
    "ignored":

    PLAY RECAP ******************************************************************
    compute-0 : ok=555 (...) failed=0 skipped=484 rescued=0 ignored=0
    compute-1 : ok=60 (...) failed=1 skipped=40 rescued=0 ignored=1
    controller-0 : ok=960 (...) failed=0 skipped=709 rescued=0 ignored=0
    controller-1 : ok=920 (...) failed=0 skipped=693 rescued=0 ignored=0
    controller-2 : ok=919 (...) failed=0 skipped=693 rescued=0 ignored=0
    undercloud : ok=86 (...) failed=0 skipped=57 rescued=0 ignored=0

    To improve UX, we'll investigate an Ansible callback to properly tell
    what nodes needs to be re-deployed.

    Note: also mock copy_clouds_yaml since it wasn't tested before but it's
    failing to reach the files on the filesystem.
    Change-Id: I7d733499e74abe2cdf91526df608dc7c273bf19e

    (cherry picked from commit 5b63958105d73eadac9c598982e68ef35defa4a1)

    2) Don't run config-download for --stack-only

    We now seem to run config-download irrespective of the
    --stack-only flag. This moves the config-download
    related code within the if block.

    Change-Id: I0185cb54ac32e1ac8558d22ba4c735a02e80a470
    Closes-Bug: #1887811
    (cherry picked from commit 5805ee4dbedac673268c6c3cf2ef616b887a1a5d)

tags: added: in-stable-ussuri
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-tripleoclient (stable/train)

Fix proposed to branch: stable/train
Review: https://review.opendev.org/742202

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-tripleoclient (stable/train)

Reviewed: https://review.opendev.org/742202
Committed: https://git.openstack.org/cgit/openstack/python-tripleoclient/commit/?id=6f8134b260058fd7793abc62c9301ef0f26e355f
Submitter: Zuul
Branch: stable/train

commit 6f8134b260058fd7793abc62c9301ef0f26e355f
Author: Emilien Macchi <email address hidden>
Date: Tue Jul 21 10:10:20 2020 -0400

    [train] manual backport & squash for overcloud_deploy raise changes

    This manual backport and squash allows to backport a feature without a
    regression that was introduced. It has 2 commits:

    1) overcloud_deploy: raise at the end if Ansible Runner had exception

    In the context of MaxFailPercentage, if a node (e.g. one of 100
    computes) has any fatal error during an Ansible play and we tolerate
    some percentage of failure; we want to raise the error but at the very
    end of the deployment.

    So this patch puts the following actions in a "finally" block so they
    always execute:

    * Create overcloudrc
    * Sets the right permissions to the clouds.yaml
    * Execute _deploy_postconfig
    * Print infos like Keystone entpoint, Horizon URL, RC file location
      and deploy message (saying if there is an error or not)

    And at the very end we raise the actual AnsibleRunner trace if the
    deployment failed.

    So even if a node failed and we tolerate it, we'll still finish the
    deployment until the end, but for UX purpose we want to raise it at
    the
    very end.
    Note that when it fails and it's tolerated, Ansible prints the node as
    "ignored":

    PLAY RECAP
    ******************************************************************
    compute-0 : ok=555 (...) failed=0 skipped=484 rescued=0
    ignored=0
    compute-1 : ok=60 (...) failed=1 skipped=40 rescued=0
    ignored=1
    controller-0 : ok=960 (...) failed=0 skipped=709 rescued=0
    ignored=0
    controller-1 : ok=920 (...) failed=0 skipped=693 rescued=0
    ignored=0
    controller-2 : ok=919 (...) failed=0 skipped=693 rescued=0
    ignored=0
    undercloud : ok=86 (...) failed=0 skipped=57 rescued=0
    ignored=0

    To improve UX, we'll investigate an Ansible callback to properly tell
    what nodes needs to be re-deployed.

    Note: also mock copy_clouds_yaml since it wasn't tested before but
    it's
    failing to reach the files on the filesystem.

    2) Don't run config-download for --stack-only

    We now seem to run config-download irrespective of the
    --stack-only flag. This moves the config-download
    related code within the if block.

    Change-Id: I9c52a790b55175310b8cecaeb6d7a23950cff271
    Closes-Bug: #1887811

tags: added: in-stable-train
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/python-tripleoclient 12.4.0

This issue was fixed in the openstack/python-tripleoclient 12.4.0 release.

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.