undercloud install artifacts no longer saved after generation

Bug #1921975 reported by James Slagle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
High
James Slagle

Bug Description

Patch https://review.opendev.org/c/openstack/python-tripleoclient/+/775302 changed the call args to utils.archive_deploy_artifacts, causing tripleo deploy to create the generated tarball of install artifacts in the templates directory itself, and then delete that directory during clean up.

we need to fix tripleo deploy to make sure the tarball is saved and use a consistent working directory, not just the home dir. Especially since tripleo deploy can be used to deploy multiple different stacks, we have existing file collisions when everything is defaulted to just use the same directory.

Changed in tripleo:
status: New → Confirmed
importance: Undecided → High
milestone: none → wallaby-rc1
assignee: nobody → James Slagle (james-slagle)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-tripleoclient (master)

Reviewed: https://review.opendev.org/c/openstack/python-tripleoclient/+/783993
Committed: https://opendev.org/openstack/python-tripleoclient/commit/ecafbae4ee7c403a3ef62e362c261585aabbec5c
Submitter: "Zuul (22348)"
Branch: master

commit ecafbae4ee7c403a3ef62e362c261585aabbec5c
Author: James Slagle <email address hidden>
Date: Tue Mar 30 22:15:41 2021 -0400

    Use a consistent working directory for tripleo deploy

    When
    https://review.opendev.org/c/openstack/python-tripleoclient/+/775302
    merged, it changed the function signature of
    utils.archive_deploy_artifacts, but the tripleo deploy code was not
    updated to pass the right arguments. This caused the templates directory
    to be considered the working directory and the artifact tarball was
    generated in that directory, and then promptly deleted during the
    cleanup phase.

    This patch updates tripleo deploy to pass the right arguments to
    archive_deploy_artifacts, and also use a consistent working directory
    based on the stack name under ~/tripleo-deploy instead of defaulting to
    the home dir. This is a cleaner approach than just leaving all the files
    in the home dir, especially given that tripleo deploy can deploy
    multiple stacks, and if the same directory was used as the default,
    there would be file collisions.

    Closes-Bug: #1921975
    Signed-off-by: James Slagle <email address hidden>
    Change-Id: Idded7faba1ff6c811b94503c559029aeeaca6a06

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

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/python-tripleoclient/+/790110

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

Reviewed: https://review.opendev.org/c/openstack/python-tripleoclient/+/790110
Committed: https://opendev.org/openstack/python-tripleoclient/commit/9f1c1ccce67aa10520e27fc45e697c924e8f7f0e
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 9f1c1ccce67aa10520e27fc45e697c924e8f7f0e
Author: James Slagle <email address hidden>
Date: Tue Mar 30 22:15:41 2021 -0400

    Use a consistent working directory for tripleo deploy

    When
    https://review.opendev.org/c/openstack/python-tripleoclient/+/775302
    merged, it changed the function signature of
    utils.archive_deploy_artifacts, but the tripleo deploy code was not
    updated to pass the right arguments. This caused the templates directory
    to be considered the working directory and the artifact tarball was
    generated in that directory, and then promptly deleted during the
    cleanup phase.

    This patch updates tripleo deploy to pass the right arguments to
    archive_deploy_artifacts, and also use a consistent working directory
    based on the stack name under ~/tripleo-deploy instead of defaulting to
    the home dir. This is a cleaner approach than just leaving all the files
    in the home dir, especially given that tripleo deploy can deploy
    multiple stacks, and if the same directory was used as the default,
    there would be file collisions.

    Closes-Bug: #1921975
    Signed-off-by: James Slagle <email address hidden>
    Change-Id: Idded7faba1ff6c811b94503c559029aeeaca6a06

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

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tripleo-quickstart-extras (master)

Reviewed: https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/784077
Committed: https://opendev.org/openstack/tripleo-quickstart-extras/commit/80032da4f8d1d314c408425b093d8799f5657b0c
Submitter: "Zuul (22348)"
Branch: master

commit 80032da4f8d1d314c408425b093d8799f5657b0c
Author: James Slagle <email address hidden>
Date: Wed Mar 31 07:33:41 2021 -0400

    Collect the old and new path for outputs/passwords first

    Now that Idded7faba1ff6c811b94503c559029aeeaca6a06 has merged, passwords
    for tripleo deploy are written to the consistent working directory, so
    both the old and new locations need to be collected in our job logs.

    We collect the new path first with first_found, since it will be the
    default path going forward.

    Partial-Bug: #1921975
    Signed-off-by: James Slagle <email address hidden>
    Change-Id: Iec4c477bf294514bbf9375fc77f44f5b37334bdb

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/python-tripleoclient 17.0.0

This issue was fixed in the openstack/python-tripleoclient 17.0.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.