openstack-charmers / release-tools Goto Github PK

This is necessary so that people know how to configure where to get the recipes/config for launchpad.

This is an oddity, but basically there is no stable version of the fixture charms, and this breaks those bundles. These charms are:

• keystone-kerberos
• neutron-api-plugin-arista
• trilio-horizon-plugin
• trilio-data-mover
• trilio-wlm
• trilio-dm-api

These need to be handled by the do-batch script and friends so they don't get updated during the release.

The additional lines are for tempest:

git+https://opendev.org/openstack/tempest.git#egg=tempest;python_version>='3.6'
tempest;python_version<'3.6'

Either we need to find a way to handle custom requirements (maybe via an 'extra-requirements.txt' or something) or change the tools to handle these extra requirements.

Update list here in description

source-zaza/test-requirements.text:

• oslo.i18n < 4.0.0; python_version < 3.6
• oslo.i18n;python_version >= 3.6

https://bugs.launchpad.net/charms.ceph/+bug/1849722

At present, the charmcraft.yaml file for reactive charms uses a set of stage/part overrides to complete the build rather than using the reactive plugin. This, due to some env variable name changes has meant that we are pinned to 1.5/stable (of charmcraft).

It would be better to use the reactive plugin and enhance that with patches so that we can unpin 1.5/stable and also have a more resilient charmcraft build going forwards. Also see: #217 comment on global/source-zaza/charmcraft-build-lock-file.yaml. @freyes

Ubuntu Focal ships with Python 3.8, Ubuntu Jammy ships with Python 3.10. For any charm with anything other than the most basic wheelhouse dependencies, building the charm for Python 3.8 and expect it to run on a Python 3.10 system does not really work well.

Charmcraft and charmhub give us the tools to fix this, but the current build model prevents the use of the long awaited functionality.

At present the build target for reactive charms relies on a rename.sh script which renames all *.charm files in the top level charm directory to something the functional test gate can recognize for deployment.

This does not work well for charms that specify multiple bases, for example:

bases:
  - build-on:
      - name: ubuntu
        channel: "20.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "20.04"
        architectures: [amd64, s390x, ppc64el, arm64]
  - build-on:
      - name: ubuntu
        channel: "22.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "22.04"
        architectures: [amd64, s390x, ppc64el, arm64]

With the above configuration charmcraft will produce the following files:

my-charm_ubuntu-20.04-amd64-s390x-ppc64el-arm64.charm
my-charm_ubuntu-22.04-amd64-s390x-ppc64el-arm64.charm

We ought to remove the rename.sh script and add support in the CI to make use of the correct charm for the correct target.

script voting assignment to charmers for their review to speed up vote/review process

Having repo-info is a nice way to preserve commit hash information (

When 'charm push' is invoked, it tries to obtain commit information based on vcs-specific dot files in the current directory. For classic charms this seems to happen automatically as they are not pre-processed, for reactive this is not the case as they are built into a separate directory that does not contain a dot-file.

https://git.io/vxPvs

Example:
charm show cs:keystone --all

...
extra-info:
  vcs-revisions:
  - authors:
    - email: corey.bryant@[email protected]
      name: Corey Bryant
    commit: 3a4faf4df4794b6031b49079b2c56309a3578a7f
    date: 2018-03-12T14:15:26-04:00
    message: |-
      Update SSL/https documentation
...
      Change-Id: I2e0140f909ef2c57182895f37cf191b6bc80157b
      Closes-Bug: #1754682
      (cherry picked from commit 3384ddcb87a2c7621719c8844cf5a24a25936d48)

Should have a master release script which executes subscripts for release - with built in validation, tests, git diff outputs, and requiring typed response, e.g. 'YES'

Essentially, this distinction is:

• charms.txt - all the charms that need to have their requirements.txt, tox.ini, etc. maintained (along with to-be-announced upper-constraints.txt) that we want to keep in sync across all the charms.
• release-charms.txt - the charms that get pushed to the charm store as stable releases.

i.e. charms.txt is ALL the charms. release-charms.txt is a subset of the released/SLA charms.

The tooling will need to be adjusted so that they use the correct charms.txt

When building a layer, the resultant top level dir name for the built artifact will be:

• the name value from metadata.yaml, if it exists
• or, the local directory (repo or checkout dir) name if metadata.yaml doesn't exist or doesn't declare a name.

The scripts and wrappers which do charm builds need to understand that and act accordingly.

I may be using the wrong version of Tox, but when I tried to run tox with the fetch-charms target Tox the positional args were not passed to fetch-charms.py. The positional args were consumed by Tox. This command, for example, returned the help from Tox instead of fetch-charms.py

tox -e fetch-charms -h

I tried a few variations on running Tox and fetch-charms, like adding the -- after fetch-charms, since that appears to be what Tox expects. This did invoke fetch-charms, but fetch-charms was ignoring the input as in this example:

tox -e fetch-charms -- --section openstack
fetch-charms: commands[0]> python3 /home/jadon/work-projects/release-tools/fetch-charms.py -- --section openstack
usage: fetch-charms.py [-h] [--log {DEBUG,INFO,WARN,ERROR,CRITICAL}] --section SECTION [--charm CHARM]
                       [--ignore-charm IGNORE_CHARM] [--worktree WORKTREE] [--worktree-dir WORKTREE_DIR] [--branch BRANCH]
                       [--dir DIRECTORY] [--replace] [--ignore-failure] [--checkout-topic CHECKOUT_TOPIC]
                       [--skip-if-present] [--reuse]
fetch-charms.py: error: the following arguments are required: --section/-s
fetch-charms: exit 2 (0.05 seconds) /home/jadon/work-projects/release-tools> python3 /home/jadon/work-projects/release-tools/fetch-charms.py -- --section openstack pid=231871
  fetch-charms: FAIL code 2 (0.07=setup[0.02]+cmd[0.05] seconds)
  evaluation failed :( (0.10 seconds)

If I did the command without -- I got the following:

tox -e fetch-charms --section openstack
usage: tox [-h] [--colored {yes,no}] [-v | -q] [--exit-and-dump-after seconds] [-c file] [--workdir dir] [--root dir] [--runner {virtualenv}] [--version] [--no-provision [REQ_JSON]] [--no-recreate-provision] [-r] [-x OVERRIDE]
           {run,r,run-parallel,p,depends,de,list,l,devenv,d,config,c,quickstart,q,exec,e,legacy,le} ...
tox: error: unrecognized arguments: --section openstack
hint: if you tried to pass arguments to a command use -- to separate them from tox ones

I was able to run Tox with the fetch-charms target by removing the -- from the declaration in tox.ini for the target testenv:fetch-charms. This declaration made fetch-charms work for me:

[testenv:fetch-charms]
basepython = python3
deps = -r{toxinidir}/requirements.txt
commands = python3 {toxinidir}/fetch-charms.py {posargs}

I am using Tox 4, but I got this same behavior on Tox 3. Am I missing something or do I need to update tox.ini to remove the -- before {posargs}?

ops based charms are bit different from classic and reactive charms. So it would be good to manage a template for ops charms.
e.g. https://opendev.org/openstack/charm-ceph-mon/src/branch/master/requirements.txt

The mysql-innodb-cluster charm now specifies a resource with a .snap extension. The resource tools build a resource with a .zip extension. Thus the charm pusher won't push the charm with the following error:

ERROR cannot get resource: cs:~openstack-charmers-next/mysql-innodb-cluster-20 has no "mysql-shell" resource
+ charm attach 'cs:~openstack-charmers-next/mysql-innodb-cluster-20' mysql-shell=resource.zip

Need to update the tool to create the resource with the same extension, and that means adding the extension to the resources.txt file.

Also we probably want to remove this: https://github.com/openstack-charmers/release-tools/blob/master/_update-tox-files#L54

        # Death to py27
        sed -e "s#python-charm-jobs#python35-charm-jobs#g" -i charms/$charm/.zuul.yaml

The 'linting' script makakes assumptions on the URL for the upstream project, but we can parse it from the .gitreview. Enhance it to make it more resilient. From #217:

$ REPO=$(grep "^project=.*" .gitreview | awk -F'=' '{print $2}')
$ echo $REPO
openstack/charm-octavia.git
$ echo ${REPO%.*}
openstack/charm-octavia

Since we are already parsing the project name, maybe we should do the same with the gerrit host and port, specially considering now review.opendev.org is the host we should use instead of review.openstack.org

When releasing 20.08, we noticed two issues in

./update-stable-charms 20.08  # running stable-branch-updates unter the hood

especially at https://github.com/openstack-charmers/release-tools/blob/master/stable-branch-updates#L65

1. this block won't pin charms.openstack in src/wheelhouse.txt and test-requirements.txt if src/layer.yaml doesn't contain layer:openstack. For ovn-dedicated-chassis this led to patchset 1. This is wrong because this charm pulls layer:openstack transitively through layer:ovn. So in fact this script should have done the pinning unconditionally.
2. also ideally this script should have gone the extra mile and created an src/wheelhouse.txt to also pin what comes from layers transitively.

A correct script would have created patchset 2 directly.

osci.yaml has been updated when the charmhub migration happened some time ago.
https://github.com/openstack-charmers/release-tools/search?q=charm-unit-jobs-py38

However, since then release-tools hasn't have a way to keep it up-to-date. For example, the following update deleted the definition of testenv:py38 but oscsi.yaml in each charm still runs charm-unit-jobs-py38.

https://github.com/openstack-charmers/release-tools/pull/234/files#diff-787e12a93f77560a0ba72920b7c164e836e6d279b40e95cae43d2e2969b04fdd

If tox.ini is supposed to be managed centrally, osci.yaml should be managed in the same manner.

Since yesterday (2021-07-20) the pip resolver seems to behave differently and fails on following conflicts:

The conflict is caused by:
    The user requested zaza 0.0.2.dev1 (from git+https://github.com/openstack-charmers/zaza.git#egg=zaza;python_version>='3.0')
    zaza-openstack 0.0.1.dev1 depends on zaza 0.0.2.dev1 (from git+https://github.com/openstack-charmers/zaza.git#egg=zaza)

The conflict is caused by:
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.8.3 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.8.2 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.8.1 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.8 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.7 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.6 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.5 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.3 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.2 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.7.0 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.6.1 depends on jsonschema<=2.5.1
    tempest 27.0.1.dev70 depends on jsonschema>=3.2.0
    charm-tools 2.6.0 depends on jsonschema<=2.5.1
    zaza 0.0.2.dev1 depends on PyYAML
    zaza-openstack 0.0.1.dev1 depends on PyYAML
    tempest 27.0.1.dev70 depends on PyYAML>=3.12
    charm-tools 2.5.1 depends on pyyaml==3.11
    zaza 0.0.2.dev1 depends on PyYAML
    zaza-openstack 0.0.1.dev1 depends on PyYAML
    tempest 27.0.1.dev70 depends on PyYAML>=3.12
    charm-tools 2.5.0 depends on pyyaml==3.11
    zaza 0.0.2.dev1 depends on PyYAML
    zaza-openstack 0.0.1.dev1 depends on PyYAML
    tempest 27.0.1.dev70 depends on PyYAML>=3.12
    charm-tools 2.4.5 depends on pyyaml==3.11
    zaza 0.0.2.dev1 depends on PyYAML
    zaza-openstack 0.0.1.dev1 depends on PyYAML
    tempest 27.0.1.dev70 depends on PyYAML>=3.12
    charm-tools 2.4.4 depends on pyyaml==3.11

The first conflict is easy to solve by removing ;python_version>='3.0' in test-requirements.txt

The second conflict is legit: we want to install the latest tempest (we need it as a binary), but at the same time we want to install charm-tools, which pins older libraries to keep py3.5 support. The solution: we don't actually need to install charm-tools and tempest in the same venvs. charm-tools is needed for pep8 whereas tempest is needed for functional tests (Zaza runs). This has been solved properly in this repo: https://github.com/openstack-charmers/charmed-openstack-tester/blob/master/tox.ini#L29

This is hitting us in all classic charms. So far seen on:

• ceilometer-agent
• glance
• neutron-api (e.g. on this review: https://review.opendev.org/c/openstack/charm-neutron-api/+/801513)

I'm working on a fix.

At present, the (soon to be) add-build-lock-file replaces the charmcraft.yaml with ./global/source-zaza/charmcraft-build-lock-file.yaml so that a build.lock file can be generated in the repo. It would be nice for stable charms if this was integrated into the master branch of reactive charms such that the tox.ini can handle add-build-lock-file directly.

osci runs the CI jobs on Bionic, this version of tox (2.5) will automatically upgrade the packages at virtualenv creation and any pinning won't have effect.

The recently version of setuptools (58.0) dropped the support for use_2to3=true which is needed to install blessings (an indirect dependency of charm-tools).

More details on the beahvior of tox and virtualenv creation can be found at tox-dev/tox#448

An attempt to workaround the issue using a wrapper around pip based on what was done zaza can be found at https://review.opendev.org/c/openstack/charm-ceph-fs/+/810022