[openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins
Doug Hellmann
doug at doughellmann.com
Tue Jun 26 15:19:05 UTC 2018
Excerpts from Matthew Treinish's message of 2018-06-26 10:37:54 -0400:
> On Tue, Jun 26, 2018 at 10:12:30AM -0400, Doug Hellmann wrote:
> > Excerpts from Matthew Treinish's message of 2018-06-26 09:52:09 -0400:
> > > On Tue, Jun 26, 2018 at 08:53:21AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100:
> > > > > On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez, <thierry at openstack.org> wrote:
> > > > >
> > > > > > Dmitry Tantsur wrote:
> > > As for this whole thread I don't understand any of the points being brought up
> > > in the original post or any of the follow ons, things seem to have been confused
> > > from the start. The ask from users at the summit was simple. When a new OpenStack
> > > release is pushed we push a tempest release to mark that (the next one will be
> > > 19.0.0 to mark Rocky). Users were complaining that many plugins don't have a
> > > corresponding version to mark support for a new release. So when trying to run
> > > against a rocky cloud you get tempest 19.0.0 and then a bunch of plugins for
> > > various services at different sha1s which have to be manually looked up based
> > > on dates. All users wanted at the summit was a tag for plugins like tempest
> > > does with the first number in:
> > >
> > > https://docs.openstack.org/tempest/latest/overview.html#release-versioning
> > >
> > > which didn't seem like a bad idea to me. I'm not sure the best mechanism to
> > > accomplish this, because I agree with much of what plugin maintainers were
> > > saying on the thread about wanting to control their own releases. But the
> > > desire to make sure users have a tag they can pull for the addition or
> > > removal of a supported release makes sense as something a plugin should do.
> >
> > We don't coordinate versions across projects anywhere else, for a
> > bunch of reasons including the complexity of coordinating the details
> > and the confusion it causes when the first version of something is
> > 19.0.0. Instead, we list the compatible versions of everything
> > together on a series-specific page on releases.o.o. That seems to
> > be enough to help anyone wanting to know which versions of tools
> > work together. The data is also available in YAML files, so it's easy
> > enough to consume by automation.
> >
> > Would that work for tempest and it's plugins, too?
>
> That is exactly what I had in mind. I wasn't advocating all plugins use the same
> version number for releases, for the same reasons we don't do that for service
> projects anymore. Just that there is a release for a plugin when they add
> support for a new service release so that users can know which version to
> install.
>
> > Is the problem that the versions are not the same, or that some of the
> > plugins are not being tagged at all?
> >
>
> While I don't pay attention to all the plugins, the impression I got was that
> it was the latter and some plugins aren't pushing releases at all. Or if they
> are there is no clear version to use for a specific openstack release.
OK, that should be easy enough to work out a solution to. The release
team can remind project teams to tag their tempest plugin(s) when they
prepare their other releases at the end of the cycle, for example.
29 out of 40 repos that have "tempest" in the name have not been
tagged via the releases repo. Not all of those are plugins. Here's
a list:
$ for repo in $(grep openstack/ reference/projects.yaml | grep tempest |
cut -f2- -d- | cut -f2 -d' ') ; do (echo -n $repo; cd ../releases/; if
grep -q $repo deliverables/*/*.yaml ; then echo ' FOUND'; else
echo ' NOT FOUND'; fi); done
openstack/barbican-tempest-plugin NOT FOUND
openstack/blazar-tempest-plugin NOT FOUND
openstack/cinder-tempest-plugin NOT FOUND
openstack/cloudkitty-tempest-plugin NOT FOUND
openstack/congress-tempest-plugin NOT FOUND
openstack/designate-tempest-plugin FOUND
openstack/ec2api-tempest-plugin NOT FOUND
openstack/freezer-tempest-plugin NOT FOUND
openstack/heat-tempest-plugin NOT FOUND
openstack/tempest-horizon NOT FOUND
openstack/ironic-tempest-plugin FOUND
openstack/networking-generic-switch-tempest-plugin NOT FOUND
openstack/keystone-tempest-plugin NOT FOUND
openstack/kuryr-tempest-plugin FOUND
openstack/magnum-tempest-plugin NOT FOUND
openstack/manila-tempest-plugin NOT FOUND
openstack/mistral-tempest-plugin NOT FOUND
openstack/monasca-tempest-plugin FOUND
openstack/murano-tempest-plugin NOT FOUND
openstack/neutron-tempest-plugin NOT FOUND
openstack/octavia-tempest-plugin NOT FOUND
openstack/charm-tempest NOT FOUND
openstack/openstack-ansible-os_tempest FOUND
openstack/puppet-tempest FOUND
openstack/tempest FOUND
openstack/tempest-plugin-cookiecutter NOT FOUND
openstack/tempest-lib NOT FOUND
openstack/tempest-stress NOT FOUND
openstack/python-tempestconf FOUND
openstack/senlin-tempest-plugin NOT FOUND
openstack/solum-tempest-plugin NOT FOUND
openstack/telemetry-tempest-plugin NOT FOUND
openstack/tempest-tripleo-ui NOT FOUND
openstack/tripleo-common-tempest-plugin NOT FOUND
openstack/trove-tempest-plugin NOT FOUND
openstack/vitrage-tempest-plugin FOUND
openstack/watcher-tempest-plugin NOT FOUND
openstack/oswin-tempest-plugin FOUND
openstack/zaqar-tempest-plugin NOT FOUND
openstack/zun-tempest-plugin FOUND
More information about the OpenStack-dev
mailing list