Open Stack

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:
> > > > > > [...]
> > > > > > My suggestion: tempest has to be compatible with all supported releases
> > > > > > (of both services and plugins) OR be branched.
> > > > > > [...]
> > > > > I tend to agree with Dmitry... We have a model for things that need
> > > > > release alignment, and that's the cycle-bound series. The reason tempest
> > > > > is branchless was because there was no compatibility issue. If the split
> > > > > of tempest plugins introduces a potential incompatibility, then I would
> > > > > prefer aligning tempest to the existing model rather than introduce a
> > > > > parallel tempest-specific cycle just so that tempest can stay
> > > > > release-independent...
> > > > >
> > > > > I seem to remember there were drawbacks in branching tempest, though...
> > > > > Can someone with functioning memory brain cells summarize them again ?
> > > > >
> > > > 
> > > > 
> > > > Branchless Tempest enforces api stability across branches.
> > > 
> > > I'm sorry, but I'm having a hard time taking this statement seriously
> > > when the current source of tension is that the Tempest API itself
> > > is breaking for its plugins.
> > > 
> > > Maybe rather than talking about how to release compatible things
> > > together, we should go back and talk about why Tempest's API is changing
> > > in a way that can't be made backwards-compatible. Can you give some more
> > > detail about that?
> > > 
> > 
> > Well it's not, if it did that would violate all the stability guarantees
> > provided by Tempest's library and plugin interface. I've not ever heard of
> > these kind of backwards incompatibilities in those interfaces and we go to
> > all effort to make sure we don't break them. Where did the idea that
> > backwards incompatible changes where being introduced come from?
> 
> In his original post, gmann said, "There might be some changes in
> Tempest which might not work with older version of Tempest Plugins."
> I was surprised to hear that, but I'm not sure how else to interpret
> that statement.

I have no idea what he means here either. If we went off and broke plugins using
a defined stable interface with changes on master we would breaking all the
stability guarantees Tempest provides on those interfaces. That's not something
we do, and have review processes and testing to prevent. The only thing I can
think of is removal of an interface, but that is pretty rare and when we do we
go through the standard deprecation procedure when we do that.

> 
> > 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.

-Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180626/1ba29a03/attachment.sig>