[openstack-dev] [release][infra][python3] how to handle release tools for python 3

Doug Hellmann doug at doughellmann.com
Fri Jun 2 16:12:42 UTC 2017


As we discussed in the team meeting today, I have filed reviews to add a
Python 3.5 unit test job to the release-tools repository:

https://review.openstack.org/470350  update semver module for python 3.5
https://review.openstack.org/470352  add python 3.5 unit test job for release-tools repository

There are 2 remaining tools that we use regularly that haven't been
ported.

openstack-infra/project-config/jenkins/scripts/release-tools/launchpad_add_comment.py
requires launchpadlib, which has at least one dependency that is not
available for Python 3. I propose that we continue to run this script
under Python 2, until all projects are migrated to storyboard and we can
drop it completely.

openstack-infra/release-tools/announce.sh uses some python programs in
the release-tools repository. Those work under python 3, but they are a
bit odd because they are the last remaining tools used by the automation
that live in that git repo. Everything else has either moved to
openstack/releases or openstack-infra/project-config. If we move these
tools, we will have all of our active scripts in a consistent place.

1. If we move the scripts to openstack/releases then we can easily
use the release note generation tool as part of the validation jobs,
and eliminate (or at least reduce) issues with release announcement
failures. The actual announcement job will have to clone the releases
repo to run the tool, but it already has to do that with the
release-tools repo.

2. The other option is to move the scripts to
openstack-infra/project-config.  I think this will end up being
more work, because that repository is not set up to encourage using
tox to configure virtualenvs where we can run console scripts, and
these tools rely on that technique right now. If we were starting
from scratch I think it would make sense to put them in project-config
with the other release tools, but they were designed in a way that
makes that more work right now.

Before I start working on option 1, I wanted to get some feedback from
the rest of the team.

Doug



More information about the OpenStack-dev mailing list