[stable] Make version pinning optional

[sombrafam]

The OVN charms prepared for the upgrade from OVN 20.03 to newer versions by unconditionally enabling version pinning.

Since then we have reached agreement with upstream that rolling upgrades should work when upgrading within the previous upstream LTS version and the next.

Having the pinning enabled may cause unnecessary grief for anyone already upgraded to OVN 22.03.

Add a charm configuration option to allow controlling the version pinning.

Closes-Bug: #2030944
Signed-off-by: Frode Nordahl [email protected]
(cherry picked from commit f68ecbd) (cherry picked from commit 2a61104) (cherry picked from commit bde8c8c)

[fnordahl]

@sombrafam your approach looks interesting however I wonder if it could also be solved by cherry-picking commit e3d4e0c and commit 1e312c8?

[sombrafam]

So, I considered that 20.04 is supported across focal and jammy, and therefore would make sense to test the Python versions present there. Does that make sense?

[dosaboy]

the stable/20.03 branch is currently failing pep8 tests with:

$ tox -epep8
pep8: commands[0]> flake8 actions lib unit_tests
lib/charms/ovn_charm.py:296:5: F811 redefinition of unused 'enable_openstack' from line 271
unit_tests/test_lib_charms_ovn_charm.py:354:12: E275 missing whitespace after keyword
unit_tests/test_lib_charms_ovn_charm.py:355:12: E275 missing whitespace after keyword
pep8: exit 1 (0.17 seconds) /home/ubuntu/layer-ovn> flake8 actions lib unit_tests pid=4428
pep8: FAIL code 1 (0.20=setup[0.03]+cmd[0.17] seconds)
evaluation failed :( (0.32 seconds)

So even if we fix the ability to run tests they won't pass. These were fixed by other patches that have not been backported:

61869ad
2b303a4

To get things moving I will propose a backport of these patches and combine with the fix to tox to get it passing.

[dosaboy]

#91 proposed. Once that is landed you can rebase your patch without the extras and should work this time.

[sombrafam]

#91 proposed. Once that is landed you can rebase your patch without the extras and should work this time.

That doesn't address the issue of not having coverage in Focal. We should have that since 20.03 runs in Focal and Jammy.

[dosaboy]

#91 proposed. Once that is landed you can rebase your patch without the extras and should work this time.

That doesn't address the issue of not having coverage in Focal. We should have that since 20.03 runs in Focal and Jammy.

How would you run 20.03 on Jammy? To get to Jammy you would also have to upgrade to 22.03 since that is the version of ovn in Jammy.

[dosaboy]

#91 proposed. Once that is landed you can rebase your patch without the extras and should work this time.

That doesn't address the issue of not having coverage in Focal. We should have that since 20.03 runs in Focal and Jammy.

How would you run 20.03 on Jammy? To get to Jammy you would also have to upgrade to 22.03 since that is the version of ovn in Jammy.

Also the 20.03 charms do not support Jammy, see https://charmhub.io/ovn-chassis?channel=20.03/stable for example so you would never be able to run this code on Jammy.

[nicolasbock]

Use ubuntu-20.04 here or stay with ubuntu-latest

[nicolasbock]

I don't think you need to pin the OS version of the runner. Unless pip compiles a Python module the OS version shouldn't really matter.

[nicolasbock]

For future reference, here is a list of supported OS names:

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

[sombrafam]

Thanks for the review Nicolas. If I don't pin the version how will pip know that I want to run python 3.8/3.9? Since the backports are for focal, we need to use those python versions.

[nicolasbock]

The actions/setup-python action will set up the correct Python version. When you then run something using python3 or similar in the runner it will use the Python version you had set up with that action.

[sombrafam]

Where would that go? I don't see that file or section in this project or in tests.yaml file.

[nicolasbock]

It's already there:

https://github.com/openstack-charmers/charm-layer-ovn/pull/89/files#diff-95557d53bf91069e59d82b9d8fcfaf52ec84a762858983edd5ef3c9b3e4c8191R17

[sombrafam]

Ah ok, got it. So, if "python-version: [3.8, 3.9]" is set, "actions/setup-python@v2" will configure PIP for those two versions?

[nicolasbock]

Yes, it will create two VMs, one for each of the Python versions you put in that list.

[sombrafam]

@nicolasbock do you have powers to trigger the CI? There is a build pending.

[sombrafam]

@nicolasbock do you have powers to trigger the CI? There is a build pending.

Sorry for asking again but I pushed my last commit without adding the change. Can you re-trigger it one more time?

[nicolasbock]

Sorry, no, I can't. You can rebase the commit though. That would trigger CI again.

[sombrafam]

@nicolasbock, do you have any suggestions on how to fix this or debug this? I can't reproduce the issue locally, and it's only occurring here.