stx/vault-armada-app uses soon-to-be deprecated pip install --use-deprecated legacy-resolver

[Ghada Khalil]

Brief Description
-----------------
Opened on behalf of <email address hidden>

The pip team is planning to depreciate the '--use-deprecated legacy-resolver'
install option. While a firm date has yet to be set, We need to be ready for
the change.

Our usage seems to be confined to 'tox.ini' files. When the upstream pip change
change is delivered, we can expect.
- Build failures due to failed unit tests
- Zuul to vote -q on code reviews in some repos

This LP tracks addressing the issue with the following files:
cgcs-root/stx/vault-armada-app/python-k8sapp-vault/k8sapp_vault/tox.ini

Severity
--------
Major:

Steps to Reproduce
------------------
Scan source code with ....
grep -r 'use-deprecated' $MY_REPO

Expected Behavior
------------------
Not found

Actual Behavior
----------------
Found 8 files using the offending option

Reproducibility
---------------
100%

System Configuration
--------------------
N/A

Branch/Pull Time/Commit
-----------------------
March 9, 2022

Last Pass
---------
N/A

Timestamp/Logs
--------------
N/A

Test Activity
-------------
Build

Workaround
----------
N/A

[Ghada Khalil (gkhalil)]

Screening: stx.8.0 / there is no hard deadline for this. Doesn't appear that any other open-infra projects are actively addressing these issues either. Park until after stx.7.0 and target for stx.8.0

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/vault-armada-app/+/848891
Committed: https://opendev.org/starlingx/vault-armada-app/commit/fc80ae3738c074e3ef84be810fffec5d45a58653
Submitter: "Zuul (22348)"
Branch: master

commit fc80ae3738c074e3ef84be810fffec5d45a58653
Author: Karla Felix <email address hidden>
Date: Wed Jul 6 14:55:53 2022 -0400

    Remove --use-deprecated legacy-resolver flag

    The pip team is planning to depreciate the
    '--use-deprecated legacy-resolver'install option.
    While a firm date has yet to be set, We need to be
    ready for the change.

    Test Plan*:

    PASS: Verified that tox runs without issues
    PASS: Generate Vault package.
    PASS: Upload and apply Vault package and check if pod
          is running.

    Note(*): Tested on kubernetes 1.21.8

    Closes-bug:1966076

    Signed-off-by: Karla Felix <email address hidden>
    Change-Id: I582378ff198430c182fd9197976e9041f2910680

[Ghada Khalil (gkhalil)]

This change will be included in stx.7.0 since it merged before the release branch creation

[Al Bailey (albailey1974)]

The legacy resolver still exists in the tox.ini for this repo
https://github.com/starlingx/vault-armada-app/commit/fc80ae3738c074e3ef84be810fffec5d45a58653

[Ghada Khalil (gkhalil)]

Re-opening as requested by Al. It appears the legacy-resolver was not removed from vault after all. However, Al also noted that removing the resolver causes tox to stall for quite a long time (5-10 minutes). It was seen in the nginx repo

[Al Bailey (albailey1974)]

Adding a comment in this launchpad about nginx-ingress-controller-armada-app repo also.
I needed to add the legacy resolver to that repo in order for tox to pass.
https://review.opendev.org/c/starlingx/nginx-ingress-controller-armada-app/+/862939

When we figure out the solution for this repo (which will likely require a change in sysinv) we should be able to cleanup nginx-ingress-controller-armada-app at the same time.

[Al Bailey (albailey1974)]

legacy resolver shows error output to help troubleshoot what needs to be updated.
Here is that output

ERROR: pip's legacy dependency resolver does not consider dependency conflicts when selecting packages. This behaviour is the source of the following dependency conflicts.

oslo-policy 3.5.0 requires PyYAML>=5.1, but you'll have pyyaml 3.13 which is incompatible.
docker 6.0.0 requires requests>=2.26.0, but you'll have requests 2.25.1 which is incompatible.
kubernetes 25.3.0 requires pyyaml>=5.4.1, but you'll have pyyaml 3.13 which is incompatible.

On Debian we ship
PyYAML==5.3.1
requests==2.25.1
docker==4.1.0
kubernetes==12.0.1

So some of those issues can be resolved by updating the upper constraints for docker and kubernetes to reflect the current debian runtime