---- On Wed, 27 Jun 2018 10:19:17 +0900 Ghanshyam Mann <gm...@ghanshyammann.com> wrote ---- > ++ operator ML > > ---- On Wed, 27 Jun 2018 10:17:33 +0900 Ghanshyam Mann > <gm...@ghanshyammann.com> wrote ---- > > > > > > > > ---- On Tue, 26 Jun 2018 23:12:30 +0900 Doug Hellmann > <d...@doughellmann.com> 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, > <thie...@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 did not mean to say that Tempest will introduce the changes in backward > incompatible way which can break plugins. That cannot happen as all plugins > and tempest are branchless and they are being tested with master Tempest so > if we change anything backward incompatible then it break the plugins gate. > Even we have to remove any deprecated interfaces from Tempest, we fix all > plugins first like - > https://review.openstack.org/#/q/topic:remove-support-of-cinder-v1-api+(status:open+OR+status:merged) > > > > > What I mean to say here is that adding new or removing deprecated > interface in Tempest might not work with all released version or unreleased > Plugins. That point is from point of view of using Tempest and Plugins in > production cloud testing not gate(where we keep the compatibility). > Production Cloud user use Tempest cycle based version. Pike based Cloud will > be tested by Tempest 17.0.0 not latest version (though latest version might > work). > > > > This thread is not just for gate testing point of view (which seems to be > always interpreted), this is more for user using Tempest and Plugins for > their cloud testing. I am looping operator mail list also which i forgot in > initial post. > > > > We do not have any tag/release from plugins to know what version of > plugin can work with what version of tempest. For Example If There is new > interface introduced by Tempest 19.0.0 and pluginX start using it. Now it > can create issues for pluginX in both release model 1. plugins with no > release (I will call this PluginNR), 2. plugins with independent release (I > will call it PluginIR). > > > > Users (Not Gate) will face below issues: > > - User cannot use PluginNR with Tempest <19.0.0 (where that new interface > was not present). And there is no PluginNR release/tag as this is unreleased > and not branched software. > > - User cannot find a PluginIR particular tag/release which can work with > tempest <19.0.0 (where that new interface was not present). Only way for > user to make it work is to manually find out the PluginIR tag/commit before > PluginIR started consuming the new interface. > > > > Let me make it more clear via diagram: > > > > PluginNR > PluginIR > > > > Tempest 19.0.0 > > Add NewInterface > Use NewInterface > Use NewInterface > > > > > > Tempest 18.0.0 > > NewInterface not > present No version of PluginNR > Unknown version of PluginIR > > > > > > GATE (No Issue as latest things always being tested live ): > OK > OK > > > > User issues: > X > (does not work) Hard to > find compatible version > > > >
Adding it here as formatting issue to read it- http://paste.openstack.org/show/724347/ > > We need a particular tag from Plugins for OpenStack release, EOL of > OpenStack release like Tempest does so that user can test their old release > Cloud in easy way. > > > > -gmann > > > > > > > > > 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? > > > > > > Is the problem that the versions are not the same, or that some of the > > > plugins are not being tagged at all? > > > > > > Doug > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
