[openstack-dev] [zun][zun-ui] Priorities of new feature on Zun UI

[Shu M.]

Hi folks,

Could you let me know your thoughts for priorities of new features on Zun
UI.
Could you jump to following pad, and fill your opinions?
https://etherpad.openstack.org/p/zun-ui

Best regards,
Shu
__
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

Re: [openstack-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches

[Tony Breeds]

On Tue, Jun 26, 2018 at 09:03:40AM -0400, Doug Hellmann wrote:
> Requirements team,
> 
> At some point in the next few months we're going to want to raise
> the constraint on openstackdocstheme in all of the old branches so
> we can take advantage of a new feature for showing the supported
> status of each version of a project. That feature isn't implemented
> yet, but I thought it would be good to discuss in advance the need
> to update the dependency and how to do it.
> 
> The theme is released under an independent release model and does
> not currently have stable branches.  It depends on pbr and dulwich,
> both of which should already be in the requirements and constraints
> lists (dulwich is a dependency of reno).

The only possible gottcha is if openstackdocstheme relies on a feature
in any of pbr or dulwich which isn't in the version currently in
upper-constratints.txt.  If that happens we can easily bump those
constraints also.
 
> I think that means the simplest thing to do would be to just update
> the constraint for the theme in the stable branches. Does that seem
> right?

Yup that seems to be all there is to it.  Once the release happens the
bot will propose the constraints bump on master which someone will need
to cherry-pick onto the stable branches.

Yours Tony.


signature.asc
Description: PGP signature
__
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-dev] [nova] Nova API Office Hour

[Ghanshyam Mann]

Hi All,

From today, we will be hosting the office hour for Nova API discussions which 
will cover the Nova API priority and API Bug triage things. I have updated the 
information about agenda and time in wiki page [1].

All are welcome to join. We will continue this on every Wedneday 06.00 UTC

[1] https://wiki.openstack.org/wiki/Meetings/NovaAPI 


-gmann



__
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

Re: [openstack-dev] [tc] [all] TC Report 18-26

[Zane Bitter]

On 26/06/18 09:12, Jay Pipes wrote:
Is (one of) the problem(s) with our community that we have too small of 
a scope/footprint? No. Not in the slightest.


Incidentally, this is an interesting/amusing example of what we talked 
about this morning on IRC[1]: you say your concern is that the scope of 
*Nova* is too big and that you'd be happy to have *more* services in 
OpenStack if they took the orchestration load off Nova and left it just 
to handle the 'plumbing' part (which I agree with, while noting that 
nobody knows how to get there from here); but here you're implying that 
Kata Containers (something that will clearly have no effect either way 
on the simplicity or otherwise of Nova) shouldn't be part of the 
Foundation because it will take focus away from Nova/OpenStack.


So to answer your question:

 zaneb: yeah... nobody I know who argues for a small stable 
core (in Nova) has ever said there should be fewer higher layer services.

 zaneb: I'm not entirely sure where you got that idea from.

I guess from all the people who keep saying it ;)

Apparently somebody was saying it a year ago too :D
https://twitter.com/zerobanana/status/883052105791156225

cheers,
Zane.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-26.log.html#t2018-06-26T15:30:33


__
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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Tue, 26 Jun 2018 19:32:59 +0900 Mehdi Abaakouk  
wrote  
 > Hi, 
 >  
 > I have never understood the branchless tempest thing. Making Tempest 
 > release is a great news for me. 
 >  
 > But about plugins... Tempest already provides a API for plugins. If you 
 > are going to break this API, why not using stable branches and 
 > deprecation process like any other software ? 
 >  
 > If you do that, plugin will be informed that Tempest will soon do a 
 > breaking change. Their can update their plugin code and raise the 
 > minimal tempest version required to work. 
 >  
 > Their can do that when they have times, and not because Tempest want to 
 > release a version soon. 
 >  
 > Also the stable branch/deprecation process is well known by the 
 > whole community. 

There is no issue of backward incompatibility from Tempest and on Gate. GATE is 
always good as it is going with mater version or minimum supported version in 
plugins as you mentioned. We take care of all these things you mentioned which 
is our main goal also. 

But If we think from Cloud tester perspective where they use older version of 
tempest for particular OpenStack release but there is no corresponding 
tag/version from plugins to use them for that OpenStack release. 

Idea is here to have a tag from Plugins also like Tempest does currently for 
each OpenStack release so that user can pickup those tag and test their 
Complete Cloud. 


-gmann
 >  
 > And this will also allow them to release a version when their want. 
 >  
 > So I support making release of Tempest and Plugins, but do not support 
 > a coordinated release. 
 >  
 > Regards, 
 >  
 > On Tue, Jun 26, 2018 at 06:18:52PM +0900, Ghanshyam Mann wrote: 
 > >Hello Everyone, 
 > > 
 > >In Queens cycle,  community goal to split the Tempest Plugin has been 
 > >completed [1] and i think almost all the projects have separate repo for 
 > >tempest plugin [2]. Which means each tempest plugins are being separated 
 > >from their project release model.  Few projects have started the 
 > >independent release model for their plugins like kuryr-tempest-plugin, 
 > >ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also 
 > >planning as chatted with amotoki. 
 > > 
 > >There might be some changes in Tempest which might not work with older 
 > >version of Tempest Plugins.  For example, If I am testing any production 
 > >cloud which has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i 
 > >will be using Tempest and Aodh's , Congress's Tempest plugins. With 
 > >Independent release model of each Tempest Plugins, there might be chance 
 > >that the Aodh's or Congress's Tempest plugin versions are not compatible 
 > >with latest/known Tempest versions. It will become hard to find the 
 > >compatible tag/release of Tempest and Tempest Plugins or in some cases i 
 > >might need to patch up the things. 
 > > 
 > >During QA feedback sessions at Vancouver Summit, there was feedback to 
 > >coordinating the release of all Tempest plugins and Tempest [4] (also 
 > >amotoki talked to me on this as neutron-tempest-plugin is planning their 
 > >first release). Idea is to release/tag all the Tempest plugins and Tempest 
 > >together so that specific release/tag can be identified as compatible 
 > >version of all the Plugins and Tempest for testing the complete stack. That 
 > >way user can get to know what version of Tempest Plugins is compatible with 
 > >what version of Tempest. 
 > > 
 > >For above use case, we need some coordinated release model among Tempest 
 > >and all the Tempest Plugins. There should be single release of all Tempest 
 > >Plugins with well defined tag whenever any Tempest release is happening.  
 > >For Example, Tempest version 19.0.0 is to mark the "support of the Rocky 
 > >release". When releasing the Tempest 19.0, we will release all the Tempest 
 > >plugins also to tag the compatibility of plugins with Tempest for "support 
 > >of the Rocky release". 
 > > 
 > >One way to make this coordinated release (just a initial thought): 
 > >1. Release Each Tempest Plugins whenever there is any major version release 
 > >of Tempest (like marking the support of OpenStack release in Tempest, EOL 
 > >of OpenStack release in Tempest) 
 > >1.1 Each plugin or Tempest can do their intermediate release of minor 
 > > version change which are in backward compatible way. 
 > >1.2 This coordinated Release can be started from latest Tempest Version 
 > > for simple reading.  Like if we start this coordinated release from 
 > > Tempest version 19.0.0 then, 
 > >each plugins will be released as 19.0.0 and so on. 
 > > 
 > >Giving the above background and use case of this coordinated release, 
 > >A) I would like to ask each plugins owner if you are agree on this 
 > >coordinated release?  If no, please give more feedback or issue we can face 
 > >due to this coordinated release. 
 >  
 >  
 >  
 >  
 > >If we get the agreement from all Plugins 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Tue, 26 Jun 2018 19:12:33 +0900 Dmitry Tantsur  
wrote  
 > On 06/26/2018 11:57 AM, Ghanshyam Mann wrote:
 > > 
 > > 
 > > 
 > >    On Tue, 26 Jun 2018 18:37:42 +0900 Dmitry Tantsur 
 > >  wrote 
 > >   > On 06/26/2018 11:18 AM, Ghanshyam Mann wrote:
 > >   > > Hello Everyone,
 > >   > >
 > >   > > In Queens cycle,  community goal to split the Tempest Plugin has 
 > > been completed [1] and i think almost all the projects have separate repo 
 > > for tempest plugin [2]. Which means each tempest plugins are being 
 > > separated from their project release model.  Few projects have started the 
 > > independent release model for their plugins like kuryr-tempest-plugin, 
 > > ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also 
 > > planning as chatted with amotoki.
 > >   > >
 > >   > > There might be some changes in Tempest which might not work with 
 > > older version of Tempest Plugins.  For example, If I am testing any 
 > > production cloud which has Nova, Neutron, Cinder, Keystone , Aodh, 
 > > Congress etc  i will be using Tempest and Aodh's , Congress's Tempest 
 > > plugins. With Independent release model of each Tempest Plugins, there 
 > > might be chance that the Aodh's or Congress's Tempest plugin versions are 
 > > not compatible with latest/known Tempest versions. It will become hard to 
 > > find the compatible tag/release of Tempest and Tempest Plugins or in some 
 > > cases i might need to patch up the things.
 > >   >
 > >   > FWIW this is solved by stable branches for all other projects. If we 
 > > cannot keep
 > >   > Tempest compatible with all supported branches, we should back off our 
 > > decision
 > >   > to make it branchless. The very nature of being branchless implies 
 > > being
 > >   > compatible with all supported releases.
 > >   >
 > >   > >
 > >   > > During QA feedback sessions at Vancouver Summit, there was feedback 
 > > to coordinating the release of all Tempest plugins and Tempest [4] (also 
 > > amotoki talked to me on this as neutron-tempest-plugin is planning their 
 > > first release). Idea is to release/tag all the Tempest plugins and Tempest 
 > > together so that specific release/tag can be identified as compatible 
 > > version of all the Plugins and Tempest for testing the complete stack. 
 > > That way user can get to know what version of Tempest Plugins is 
 > > compatible with what version of Tempest.
 > >   > >
 > >   > > For above use case, we need some coordinated release model among 
 > > Tempest and all the Tempest Plugins. There should be single release of all 
 > > Tempest Plugins with well defined tag whenever any Tempest release is 
 > > happening.  For Example, Tempest version 19.0.0 is to mark the "support of 
 > > the Rocky release". When releasing the Tempest 19.0, we will release all 
 > > the Tempest plugins also to tag the compatibility of plugins with Tempest 
 > > for "support of the Rocky release".
 > >   > >
 > >   > > One way to make this coordinated release (just a initial thought):
 > >   > > 1. Release Each Tempest Plugins whenever there is any major version 
 > > release of Tempest (like marking the support of OpenStack release in 
 > > Tempest, EOL of OpenStack release in Tempest)
 > >   > >  1.1 Each plugin or Tempest can do their intermediate release of 
 > > minor version change which are in backward compatible way.
 > >   > >  1.2 This coordinated Release can be started from latest Tempest 
 > > Version for simple reading.  Like if we start this coordinated release 
 > > from Tempest version 19.0.0 then,
 > >   > >  each plugins will be released as 19.0.0 and so on.
 > >   > >
 > >   > > Giving the above background and use case of this coordinated release,
 > >   > > A) I would like to ask each plugins owner if you are agree on this 
 > > coordinated release?  If no, please give more feedback or issue we can 
 > > face due to this coordinated release.
 > >   >
 > >   > Disclaimer: I'm not the PTL.
 > >   >
 > >   > Similarly to Luigi, I don't feel well about forcing a plugin release 
 > > at the same
 > >   > time as a tempest release, UNLESS tempest folks are going to 
 > > coordinate their
 > >   > releases with all how-many-do-we-have plugins. What I'd like to avoid 
 > > is cutting
 > >   > a release in the middle of a patch chain or some refactoring just 
 > > because
 > >   > tempest happened to have a release right now.
 > > 
 > > I understand your point. But we can avoid that case if we only coordinate 
 > > on major version bump only. as i mentioned in 1.2 point, Tempest and 
 > > Tempest plugins can do their intermediate release anytime which are 
 > > nothing but backward compatible release. In this proposed model, we can do 
 > > a coordinated release for major version bump only which is happening only 
 > > on OpenStack release and EOL of any stable branch.
 > 
 > Even bigger concern: what if the plugin is actually not compatible yet? Say, 
 > you're 

Re: [openstack-dev] [Openstack-operators] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Wed, 27 Jun 2018 10:19:17 +0900 Ghanshyam Mann 
 wrote  
 > ++ operator ML
 > 
 >   On Wed, 27 Jun 2018 10:17:33 +0900 Ghanshyam Mann 
 >  wrote  
 >  >  
 >  >  
 >  >  
 >  >   On Tue, 26 Jun 2018 23:12:30 +0900 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, 
 >  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 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

++ operator ML

  On Wed, 27 Jun 2018 10:17:33 +0900 Ghanshyam Mann 
 wrote  
 >  
 >  
 >  
 >   On Tue, 26 Jun 2018 23:12:30 +0900 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, 
 >  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 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Tue, 26 Jun 2018 23:12:30 +0900 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,  
 > > > > 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

[openstack-dev] [infra] Behavior change in Zuul post pipeline

[James E. Blair]

Hi,

We recently changed the behavior* of the post pipeline in Zuul to only
run jobs for the most recently merged changes on each project's
branches.  If you were relying on the old behavior where jobs ran on
every merged change, let us know, we can make a new pipeline for that.
But for the typical case, this should result in some improvements:

1) We waste fewer build resources building intermediate build artifacts
(e.g., documentation for a version which is already obsoleted by the
change which landed after it).

2) Races in artifact build jobs will no longer result in old versions of
documentation being published because they ran on a slightly faster node
than the newer version.

If you observe any unexpected behavior as the result of this change,
please let us know in #openstack-infra.

-Jim

* The thing which implements this behavior in Zuul is the
  "supercedent"** pipeline manager[1].  Zuul has had, since the initial
  commit six years ago, a pluggable system for controlling the behavior
  in its pipelines.  To date, we have only had two pipeline managers:
  "dependent" which controls the gate, and "independent" which controls
  everything else.

[1] 
https://zuul-ci.org/docs/zuul/user/config.html#value-pipeline.manager.supercedent

** It may or may not be named after anyone you know.

__
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-dev] [all][ci][infra] Small network interface MTUs on test nodes

[Clark Boylan]

Hello everyone,

We now have more than one cloud provider giving us test node resources where we 
can expect network interfaces to have MTUs less that 1500. This is a side 
effect of running Neutron with overlay networking in the cloud providing the 
test resources. Considering we've largely made this "problem" for ourselves we 
should try to accommodate this.

I have pushed a documentation update to explain this [0] as well as job updates 
for infra managed overlays used in multinode testing [1][2]. If your jobs 
manage interfaces or bridges themselves you may need to make similar updates as 
well. (I believe that devstack + neutron already do this for you if using them).

Let the infra team know if you have any questions about this.

[0] https://review.openstack.org/#/c/578159/1/doc/source/testing.rst
[1] https://review.openstack.org/578146
[2] https://review.openstack.org/578153

Clark

__
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

Re: [openstack-dev] [tc] [all] TC Report 18-26

[Zane Bitter]

On 26/06/18 09:12, Jay Pipes wrote:

On 06/26/2018 08:41 AM, Chris Dent wrote:

Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
the TC's role as listener, mediator, and influencer lacks
definition.

Zane wrote up a blog post explaining the various ways in which the
OpenStack Foundation is 
[expanding](https://www.zerobanana.com/archive/2018/06/14#osf-expansion).


One has to wonder with 4 "focus areas" for the OpenStack Foundation [1] 
whether there is any actual expectation that there will be any focus at 
all any more.


Are CI/CD and secure containers important? [2] Yes, absolutely.

Is (one of) the problem(s) with our community that we have too small of 
a scope/footprint? No. Not in the slightest.


IMHO, what we need is focus. And having 4 different focus areas doesn't 
help focus things.


One of the upshots of this change is that when discussing stuff we now 
need to be more explicit about who 'we' are.


We, the OpenStack project, will have less stuff to focus on as a result 
of this change (no Zuul, for example, and if that doesn't make you happy 
then perhaps no 'edge' stuff will ;).


We, the OpenStack Foundation, will unquestionably have more stuff.

I keep waiting for people to say "no, that isn't part of our scope". But 
all I see is people saying "yes, we will expand our scope to these new 
sets of things


Arguably we're saying both of these things, but for different 
definitions of 'our'.


(otherwise *gasp* the Linux Foundation will gobble up all 
the hype)".


I could also speculate on what the board was hoping to achieve when it 
made this move, but it would be much better if they were to communicate 
that clearly to the membership themselves. One thing we did at the joint 
leadership meeting was essentially brainstorming for a new mission 
statement for the Foundation, and this very much seemed like a post-hoc 
exercise - we (the Foundation) are operating outside the current mission 
of record, but nobody has yet articulated what our new mission is.



Just my two cents and sorry for being opinionated,


Hey, feel free to complain to the TC on openstack-dev any time. But also 
be aware that if you actually want anything to happen, you also need to 
complain to your Individual Directors of the Foundation and/or on the 
foundation list.


cheers,
Zane.


-jay

[1] https://www.openstack.org/foundation/strategic-focus-areas/

[2] I don't include "edge" in my list of things that are important 
considering nobody even knows what "edge" is yet. I fail to see how 
people can possibly "focus" on something that isn't defined.


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

Re: [openstack-dev] [python3] building tools for the transition

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-20 11:34:10 -0400:
> I want to thank Nguyễn Trí Hải, Ma Lei, and Huang Zhiping for
> agreeing to be a part of the goal champion team for the python3
> goal for Stein.
> 
> The next step for us is to build some tools to make the process a
> little easier.
> 
> One of the aspects of this goal that makes it difficult is that we
> need to change so many repositories. There are more than 480
> repositories associated with official project teams. I do not think
> we want to edit their zuul configurations by hand. :-)
> 
> It would be ideal if we had a script that could read the
> openstack-infra/project-config/zuul.d/projects.yaml file to find
> the project settings for a repository and copy those settings into
> the right settings file within the repository. We could then review
> the patch locally before proposing the change to gerrit.  A second
> script to remove the settings from the project-config file, and
> then submit that second change as a patch that has a Depends-On
> listed for the first patch would also be useful.
> 
> Another aspect that makes it difficult is that zuul is very flexible
> with how it reads its configuration files. The configuration can
> be in .zuul.yaml, zuul.yaml, .zuul.d/*.yaml, or zuul.d/*.yaml.
> Projects have not been consistent with the way they have named their
> files, and that will make writing a script to automate editing them
> more difficult. For example, I found automaton/.zuul.yaml,
> rally/zuul.yaml, oslo.config/.zuul.d, and python-ironicclient/zuul.d.
> 
> When I was working on adding the lower-constraints jobs, I created some
> tools in https://github.com/dhellmann/openstack-requirements-stop-sync
> to help create the patches, and we may be able to reuse some of that
> code to make similar changes for this goal.
> https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/make_patches.sh
> is the script that makes the patches, and
> https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/add_job.py
> is the python script that edits the YAML file.
> 
> The task for this goal is a little more complicated, since we are
> not just adding 1 template to the existing project settings.  We
> may have to add several templates and jobs to the existing settings,
> merging the two sets together, and removing branch specifiers at
> the same time. And we may need to do that in several branches.
> 
> Would a couple of you have time to work on the script to prepare
> the patches? We can work in the openstack/goal-tools repository so
> that we can collaborate on the code in an official OpenStack
> repository (instead of using my GitHub project).
> 
> Doug

I started working on these tools today. Given the complexity, for now
the two commands only print the expected settings. The 'jobs extract'
command shows which job settings should be copied from project-config to
the zuul settings in a given branch of a repository, and 'jobs retain'
shows which jobs settings should remain in place.

Please look over the changeset
(https://review.openstack.org/#/c/578194/) and leave review comments if
you have them.

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

Re: [openstack-dev] [tc] [all] TC Report 18-26

[Fox, Kevin M]

"What is OpenStack" 

From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, June 26, 2018 6:12 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26

On 06/26/2018 08:41 AM, Chris Dent wrote:
> Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
> the TC's role as listener, mediator, and influencer lacks
> definition.
>
> Zane wrote up a blog post explaining the various ways in which the
> OpenStack Foundation is
> [expanding](https://www.zerobanana.com/archive/2018/06/14#osf-expansion).

One has to wonder with 4 "focus areas" for the OpenStack Foundation [1]
whether there is any actual expectation that there will be any focus at
all any more.

Are CI/CD and secure containers important? [2] Yes, absolutely.

Is (one of) the problem(s) with our community that we have too small of
a scope/footprint? No. Not in the slightest.

IMHO, what we need is focus. And having 4 different focus areas doesn't
help focus things.

I keep waiting for people to say "no, that isn't part of our scope". But
all I see is people saying "yes, we will expand our scope to these new
sets of things (otherwise *gasp* the Linux Foundation will gobble up all
the hype)".

Just my two cents and sorry for being opinionated,
-jay

[1] https://www.openstack.org/foundation/strategic-focus-areas/

[2] I don't include "edge" in my list of things that are important
considering nobody even knows what "edge" is yet. I fail to see how
people can possibly "focus" on something that isn't defined.

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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-26 11:19:05 -0400:

> 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

I have proposed https://review.openstack.org/578141 to update the
deliverable files for rocky to include the plugins.

I left out openstack/ec2api-tempest-plugin because it doesn't look like
ec2-api has been tagged in quite a while.

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-dev] [neutron] neutron-lib consumption patches for the Neutron Stadium and networking projects

[Miguel Lavalle]

Dear Neutron Community,

As we are all aware, over the past few cycles we have been re-homing from
Neutron to neutron-lib all the common functionality that is shared with the
OpenStack Networking family of projects. In a nutshell, the process is the
following:

   1. Shared functionality is identified in the Neutron code-base and it is
   re-homed in neutron-lib
   2. Patches are submitted to the OpenStack Networking projects with
   stable branches, to consume the newly re-homed functionality from
   neutron-lib. It is important to mention here that all that is required from
   these projects is to review and merge the patches. Boden Russel takes care
   of creating, submitting and amending these patches until they merge
   3. Once all the stable branches projects merge the corresponding
   consumption patch, the shared functionality is removed from Neutron

Lately, we have found that some projects are not merging consumption
patches, either for lack of review and / or gate issues. This prevents the
team from being able to remove re-homed functionality from Neutron. To be
able to continue making progress in the neutron-lib effort, going forward
we are going to adopt the following policy:

   1. Projects will have two weeks to review and merge neutron-lib
   consumption patches
   2. Boden will stop submitting consumption patches that fail the previous
   point. The corresponding functionality will be removed from Neutron. At
   that point, it will be the responsibility of the project in question to
   catch up with the consumption of functionality from neutron-lib

Thanks for your cooperation

Best regards

Miguel
__
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

Re: [openstack-dev] [kolla] Removing old / unused images

[Andy Smith]

Also commented as tripleo is using qdrouterd.

It's use in kolla-ansible
https://github.com/openstack/kolla-ansible/tree/master/ansible/roles/qdrouterd

and bp
https://blueprints.launchpad.net/kolla/+spec/dispatch-router-messaging-component

Thanks,
Andy

On Tue, Jun 26, 2018 at 10:52 AM Alex Schultz  wrote:

> On Tue, Jun 26, 2018 at 8:05 AM, Paul Bourke 
> wrote:
> > Hi all,
> >
> > At the weekly meeting a week or two ago, we mentioned removing some old /
> > unused images from Kolla in the interest of keeping the gate run times
> down,
> > as well as general code hygiene.
> >
> > The images I've determined that are either no longer relevant, or were
> > simply never made use of in kolla-ansible are the following:
> >
> > * almanach
> > * certmonger
> > * dind
> > * qdrouterd
> > * rsyslog
> >
> > * helm-repository
> > * kube
> > * kubernetes-entrypoint
> > * kubetoolbox
> >
> > If you still care about any of these or I've made an oversight, please
> have
> > a look at the patch [0]
> >
>
> I have commented as tripleo is using some of these. I would say that
> you shouldn't just remove these and there needs to be a proper
> deprecation policy. Just because you aren't using them in
> kolla-ansible doesn't mean someone isn't actually using them.
>
> Thanks,
> -Alex
>
> > Thanks!
> > -Paul
> >
> > [0] https://review.openstack.org/#/c/578111/
> >
> >
> __
> > 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 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 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

Re: [openstack-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches

[Matthew Thode]

On 18-06-26 09:03:40, Doug Hellmann wrote:
> Requirements team,
> 
> At some point in the next few months we're going to want to raise
> the constraint on openstackdocstheme in all of the old branches so
> we can take advantage of a new feature for showing the supported
> status of each version of a project. That feature isn't implemented
> yet, but I thought it would be good to discuss in advance the need
> to update the dependency and how to do it.
> 
> The theme is released under an independent release model and does
> not currently have stable branches.  It depends on pbr and dulwich,
> both of which should already be in the requirements and constraints
> lists (dulwich is a dependency of reno).
> 
> I think that means the simplest thing to do would be to just update
> the constraint for the theme in the stable branches. Does that seem
> right?
> 
> If we can make that happen before we start the zuul configuration
> porting work that we're going to do as part of the python3-first
> goal, then we can take advantage of those patches to trigger doc
> rebuilds in all of the projects.
> 

Yep, talked about this in the reqs channel, seems like a good idea/plan.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches

[Sean McGinnis]

> 
> The theme is released under an independent release model and does
> not currently have stable branches.  It depends on pbr and dulwich,
> both of which should already be in the requirements and constraints
> lists (dulwich is a dependency of reno).
> 
> I think that means the simplest thing to do would be to just update
> the constraint for the theme in the stable branches. Does that seem
> right?
> 

This makes sense to me. As long as their is no concern about backward
compatibility with openstackdocstheme (which I would be kind of surprised if
there were), I think this should be safe enough.

> If we can make that happen before we start the zuul configuration
> porting work that we're going to do as part of the python3-first
> goal, then we can take advantage of those patches to trigger doc
> rebuilds in all of the projects.
> 
> 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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

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

Re: [openstack-dev] [kolla] Removing old / unused images

[Alex Schultz]

On Tue, Jun 26, 2018 at 8:05 AM, Paul Bourke  wrote:
> Hi all,
>
> At the weekly meeting a week or two ago, we mentioned removing some old /
> unused images from Kolla in the interest of keeping the gate run times down,
> as well as general code hygiene.
>
> The images I've determined that are either no longer relevant, or were
> simply never made use of in kolla-ansible are the following:
>
> * almanach
> * certmonger
> * dind
> * qdrouterd
> * rsyslog
>
> * helm-repository
> * kube
> * kubernetes-entrypoint
> * kubetoolbox
>
> If you still care about any of these or I've made an oversight, please have
> a look at the patch [0]
>

I have commented as tripleo is using some of these. I would say that
you shouldn't just remove these and there needs to be a proper
deprecation policy. Just because you aren't using them in
kolla-ansible doesn't mean someone isn't actually using them.

Thanks,
-Alex

> Thanks!
> -Paul
>
> [0] https://review.openstack.org/#/c/578111/
>
> __
> 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 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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Matthew Treinish]

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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Vladyslav Drok]

On Tue, Jun 26, 2018 at 5:14 PM Vladyslav Drok  wrote:

>
> On Tue, Jun 26, 2018 at 4:58 PM Takashi Yamamoto 
> wrote:
>
>> On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann 
>> wrote:
>> > Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
>> >> Thanks a bunch for digging into this, Tony. I'll follow up with the
>> >> oauthlib maintainers and see if they'd be interested in these changes
>> >> upstream. If so, I can chip away at it. For now we'll have to settle
>> for
>> >> not treating warnings as errors to unblock our documentation gate [0].
>> >>
>> >> [0] https://review.openstack.org/#/c/577974/
>> >
>> > How are docstrings from a third-party library making their way into the
>> > keystone docs and breaking the build?
>>
>> in the same way that docstrings from os-vif affect networking-midonet
>> docs.
>> i.e. via class inheritance
>>
>> >
>> > Doug
>> >
>> >>
>> >> On 06/25/2018 07:27 PM, Tony Breeds wrote:
>> >> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
>> >> >> Keystone is hitting this, too [0]. I attempted the same solution
>> that
>> >> >> Tony posted, but no luck. I've even gone so far as removing every
>> >> >> comment from the module to see if that helps narrow down the problem
>> >> >> area, but sphinx still trips. The output from the error message
>> isn't
>> >> >> very descriptive either. Has anyone else had issues fixing this for
>> >> >> python comments, not just docstrings?
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
>> >> > I did a little digging for the keystone problem and it's due to a
>> >> > missing ':' in
>> >> >
>> https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
>> >> >
>> >> > So the correct way to fix this is to correct that in oauthlib, get it
>> >> > released and use that.
>> >> >
>> >> > I hit additional problems in that enabling -W in oauthlib, to pevent
>> >> > this happening in the future, lead me down a rabbit hole I don't
>> really
>> >> > have cycles to dig out of.
>> >> >
>> >> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
>> >> > debugging but it isn't too hard to reproduce and someone that knows
>> more
>> >> > Sphinx will be able to understand the errors better than I can.
>> >> >
>> >> >
>> >> > [1] http://paste.openstack.org/show/724271/
>> >> >
>> >> > Yours Tony.
>>
>
> This also might be related to this thread, in ironic I can see the
> following while building the docs, apart from 'Bullet list ends without a
> blank line' issue:
>
> Warning, treated as error:
> /home/vlad/work/ironic/ironic/api/app.py:docstring of
> ironic.api.app.IronicCORS:1:Error in "wsme:service" directive:
> unknown option: "module".
>
> .. wsme:service:: None
>:module: ironic.api.app
>
>Bases: :class:`oslo_middleware.cors.CORS`
>
>Ironic-specific CORS class
>
>We're adding the Ironic-specific version headers to the list of simple
>headers in order that a request bearing those headers might be accepted
> by
>the Ironic REST API.
>
> I see that there is some code in wsmeext that should be dealing with that
> if I understand correctly --
> https://github.com/openstack/wsme/blob/0.8.0/wsmeext/sphinxext.py#L356-L357
>
> Sphinx version I have is 1.7.5.
>
> Several other folks indicated that they hit it with on fresh fedora.
>

It also appears that index of :module: entry has changed:

-> if ':module:' in self.directive.result[-1]:
(Pdb) self.directive.result
ViewList(['', '.. py:module:: ironic.api.app', '', '', '.. wsme:service::
None', '   :module: ironic.api.app', '', '   Bases:
:class:`oslo_middleware.cors.CORS`'],
items=[('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app', 0), ('/home/vlad/work/ironic/ironic/api/app.py:docstring
of ironic.api.app', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of ironic.api.app',
0), ('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0)])

It is self.directive.result[-3] now, so I guess it needs to be changed to
iterate on everything in that list with that check?


>
>> >> >
>> >> >
>> >> >
>> __
>> >> > 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 Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> 

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Vladyslav Drok]

On Tue, Jun 26, 2018 at 4:58 PM Takashi Yamamoto 
wrote:

> On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann 
> wrote:
> > Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
> >> Thanks a bunch for digging into this, Tony. I'll follow up with the
> >> oauthlib maintainers and see if they'd be interested in these changes
> >> upstream. If so, I can chip away at it. For now we'll have to settle for
> >> not treating warnings as errors to unblock our documentation gate [0].
> >>
> >> [0] https://review.openstack.org/#/c/577974/
> >
> > How are docstrings from a third-party library making their way into the
> > keystone docs and breaking the build?
>
> in the same way that docstrings from os-vif affect networking-midonet docs.
> i.e. via class inheritance
>
> >
> > Doug
> >
> >>
> >> On 06/25/2018 07:27 PM, Tony Breeds wrote:
> >> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> >> >> Keystone is hitting this, too [0]. I attempted the same solution that
> >> >> Tony posted, but no luck. I've even gone so far as removing every
> >> >> comment from the module to see if that helps narrow down the problem
> >> >> area, but sphinx still trips. The output from the error message isn't
> >> >> very descriptive either. Has anyone else had issues fixing this for
> >> >> python comments, not just docstrings?
> >> >>
> >> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
> >> > I did a little digging for the keystone problem and it's due to a
> >> > missing ':' in
> >> >
> https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
> >> >
> >> > So the correct way to fix this is to correct that in oauthlib, get it
> >> > released and use that.
> >> >
> >> > I hit additional problems in that enabling -W in oauthlib, to pevent
> >> > this happening in the future, lead me down a rabbit hole I don't
> really
> >> > have cycles to dig out of.
> >> >
> >> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
> >> > debugging but it isn't too hard to reproduce and someone that knows
> more
> >> > Sphinx will be able to understand the errors better than I can.
> >> >
> >> >
> >> > [1] http://paste.openstack.org/show/724271/
> >> >
> >> > Yours Tony.
>

This also might be related to this thread, in ironic I can see the
following while building the docs, apart from 'Bullet list ends without a
blank line' issue:

Warning, treated as error:
/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS:1:Error in "wsme:service" directive:
unknown option: "module".

.. wsme:service:: None
   :module: ironic.api.app

   Bases: :class:`oslo_middleware.cors.CORS`

   Ironic-specific CORS class

   We're adding the Ironic-specific version headers to the list of simple
   headers in order that a request bearing those headers might be accepted
by
   the Ironic REST API.

I see that there is some code in wsmeext that should be dealing with that
if I understand correctly --
https://github.com/openstack/wsme/blob/0.8.0/wsmeext/sphinxext.py#L356-L357

Sphinx version I have is 1.7.5.

Several other folks indicated that they hit it with on fresh fedora.


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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Lance Bragstad]

On 06/26/2018 08:57 AM, Takashi Yamamoto wrote:
> On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann  wrote:
>> Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
>>> Thanks a bunch for digging into this, Tony. I'll follow up with the
>>> oauthlib maintainers and see if they'd be interested in these changes
>>> upstream. If so, I can chip away at it. For now we'll have to settle for
>>> not treating warnings as errors to unblock our documentation gate [0].
>>>
>>> [0] https://review.openstack.org/#/c/577974/
>> How are docstrings from a third-party library making their way into the
>> keystone docs and breaking the build?
> in the same way that docstrings from os-vif affect networking-midonet docs.
> i.e. via class inheritance

Correct, keystone relies in an interface from that library. I've reached
out to their community to see if they would be interested in the fixes
upstream [0], and they were receptive. Until then we might have to
override the offending documentation strings somehow (per Doug's
suggestion in IRC) or disable warning as errors in our build [1].

[0] https://github.com/oauthlib/oauthlib/issues/558
[1] https://review.openstack.org/#/c/577974/

>
>> Doug
>>
>>> On 06/25/2018 07:27 PM, Tony Breeds wrote:
 On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> Keystone is hitting this, too [0]. I attempted the same solution that
> Tony posted, but no luck. I've even gone so far as removing every
> comment from the module to see if that helps narrow down the problem
> area, but sphinx still trips. The output from the error message isn't
> very descriptive either. Has anyone else had issues fixing this for
> python comments, not just docstrings?
>
> [0] https://bugs.launchpad.net/keystone/+bug/1778603
 I did a little digging for the keystone problem and it's due to a
 missing ':' in
 https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820

 So the correct way to fix this is to correct that in oauthlib, get it
 released and use that.

 I hit additional problems in that enabling -W in oauthlib, to pevent
 this happening in the future, lead me down a rabbit hole I don't really
 have cycles to dig out of.

 Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
 debugging but it isn't too hard to reproduce and someone that knows more
 Sphinx will be able to understand the errors better than I can.


 [1] http://paste.openstack.org/show/724271/

 Yours Tony.


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




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

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

> 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-dev] [kolla] Removing old / unused images

[Paul Bourke]

Hi all,

At the weekly meeting a week or two ago, we mentioned removing some old 
/ unused images from Kolla in the interest of keeping the gate run times 
down, as well as general code hygiene.


The images I've determined that are either no longer relevant, or were 
simply never made use of in kolla-ansible are the following:


* almanach
* certmonger
* dind
* qdrouterd
* rsyslog

* helm-repository
* kube
* kubernetes-entrypoint
* kubetoolbox

If you still care about any of these or I've made an oversight, please 
have a look at the patch [0]


Thanks!
-Paul

[0] https://review.openstack.org/#/c/578111/

__
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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann  wrote:
> Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
>> Thanks a bunch for digging into this, Tony. I'll follow up with the
>> oauthlib maintainers and see if they'd be interested in these changes
>> upstream. If so, I can chip away at it. For now we'll have to settle for
>> not treating warnings as errors to unblock our documentation gate [0].
>>
>> [0] https://review.openstack.org/#/c/577974/
>
> How are docstrings from a third-party library making their way into the
> keystone docs and breaking the build?

in the same way that docstrings from os-vif affect networking-midonet docs.
i.e. via class inheritance

>
> Doug
>
>>
>> On 06/25/2018 07:27 PM, Tony Breeds wrote:
>> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
>> >> Keystone is hitting this, too [0]. I attempted the same solution that
>> >> Tony posted, but no luck. I've even gone so far as removing every
>> >> comment from the module to see if that helps narrow down the problem
>> >> area, but sphinx still trips. The output from the error message isn't
>> >> very descriptive either. Has anyone else had issues fixing this for
>> >> python comments, not just docstrings?
>> >>
>> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
>> > I did a little digging for the keystone problem and it's due to a
>> > missing ':' in
>> > https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
>> >
>> > So the correct way to fix this is to correct that in oauthlib, get it
>> > released and use that.
>> >
>> > I hit additional problems in that enabling -W in oauthlib, to pevent
>> > this happening in the future, lead me down a rabbit hole I don't really
>> > have cycles to dig out of.
>> >
>> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
>> > debugging but it isn't too hard to reproduce and someone that knows more
>> > Sphinx will be able to understand the errors better than I can.
>> >
>> >
>> > [1] http://paste.openstack.org/show/724271/
>> >
>> > Yours Tony.
>> >
>> >
>> > __
>> > 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 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 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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Matthew Treinish]

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,  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?

That being said things are definitely getting confused here, all andreaf was
talking about the branchless nature is ensuring we run the same tests against
service REST APIs, making sure we have API stability between releases in the
services when we say we do. (to answer ttx's question)

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.


-Matt Treinish


signature.asc
Description: PGP signature
__
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-dev] [nova]Notification update week 26

[Balázs Gibizer]

Hi,

Here is the latest notification subteam update.

Bugs


[Undecided] "IndexError: list index out of range" in 
ExceptionPayload.from_exception during resize failure 
https://bugs.launchpad.net/nova/+bug/1777540
I failed to reproduce and based on the newly provided logs in the 
parent bug https://bugs.launchpad.net/nova/+bug/1777157 this happens in 
an environment that runs heavily forked nova code. So I marked the bug 
inva

lid.

[Medium] Server operations fail to complete with versioned 
notifications if payload contains unset non-nullable fields 
https://bugs.launchpad.net/nova/+bug/1739325
This bug is still open and reportedly visible in multiple independent 
environment but I failed to find the root cause. So I'm wondering if we 
can implement a nova-manage heal-instance-flavor command for these 
environments.



Features


Sending full traceback in versioned notifications
~
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications 
has been implemented. \o/



Introduce Pending VM state
~~
The spec https://review.openstack.org/#/c/554212 still not exactly 
define what will be in the select_destination notification payload and 
seems it is deferred to Stein.



Add the user id and project id of the user initiated the instance 
action to the notification


https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
Work progressing in  https://review.openstack.org/#/c/536243


Introduce instance.lock and instance.unlock notifications
-
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances 
has been implemented \o/




Weekly meeting
--
No meeting this week. The next meeting is planned to be held on 3rd of 
June on #openstack-meeting-4 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180703T17


Cheers,
gibi


__
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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
> Thanks a bunch for digging into this, Tony. I'll follow up with the
> oauthlib maintainers and see if they'd be interested in these changes
> upstream. If so, I can chip away at it. For now we'll have to settle for
> not treating warnings as errors to unblock our documentation gate [0].
> 
> [0] https://review.openstack.org/#/c/577974/

How are docstrings from a third-party library making their way into the
keystone docs and breaking the build?

Doug

> 
> On 06/25/2018 07:27 PM, Tony Breeds wrote:
> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> >> Keystone is hitting this, too [0]. I attempted the same solution that
> >> Tony posted, but no luck. I've even gone so far as removing every
> >> comment from the module to see if that helps narrow down the problem
> >> area, but sphinx still trips. The output from the error message isn't
> >> very descriptive either. Has anyone else had issues fixing this for
> >> python comments, not just docstrings?
> >>
> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
> > I did a little digging for the keystone problem and it's due to a
> > missing ':' in 
> > https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
> >
> > So the correct way to fix this is to correct that in oauthlib, get it
> > released and use that.
> >
> > I hit additional problems in that enabling -W in oauthlib, to pevent
> > this happening in the future, lead me down a rabbit hole I don't really
> > have cycles to dig out of.
> >
> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
> > debugging but it isn't too hard to reproduce and someone that knows more
> > Sphinx will be able to understand the errors better than I can.
> >
> >
> > [1] http://paste.openstack.org/show/724271/
> >
> > Yours Tony.
> >
> >
> > __
> > 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 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

Re: [openstack-dev] [tc] [all] TC Report 18-26

[Jay Pipes]

On 06/26/2018 08:41 AM, Chris Dent wrote:

Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
the TC's role as listener, mediator, and influencer lacks
definition.

Zane wrote up a blog post explaining the various ways in which the
OpenStack Foundation is 
[expanding](https://www.zerobanana.com/archive/2018/06/14#osf-expansion).


One has to wonder with 4 "focus areas" for the OpenStack Foundation [1] 
whether there is any actual expectation that there will be any focus at 
all any more.


Are CI/CD and secure containers important? [2] Yes, absolutely.

Is (one of) the problem(s) with our community that we have too small of 
a scope/footprint? No. Not in the slightest.


IMHO, what we need is focus. And having 4 different focus areas doesn't 
help focus things.


I keep waiting for people to say "no, that isn't part of our scope". But 
all I see is people saying "yes, we will expand our scope to these new 
sets of things (otherwise *gasp* the Linux Foundation will gobble up all 
the hype)".


Just my two cents and sorry for being opinionated,
-jay

[1] https://www.openstack.org/foundation/strategic-focus-areas/

[2] I don't include "edge" in my list of things that are important 
considering nobody even knows what "edge" is yet. I fail to see how 
people can possibly "focus" on something that isn't defined.


__
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-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches

[Doug Hellmann]

Requirements team,

At some point in the next few months we're going to want to raise
the constraint on openstackdocstheme in all of the old branches so
we can take advantage of a new feature for showing the supported
status of each version of a project. That feature isn't implemented
yet, but I thought it would be good to discuss in advance the need
to update the dependency and how to do it.

The theme is released under an independent release model and does
not currently have stable branches.  It depends on pbr and dulwich,
both of which should already be in the requirements and constraints
lists (dulwich is a dependency of reno).

I think that means the simplest thing to do would be to just update
the constraint for the theme in the stable branches. Does that seem
right?

If we can make that happen before we start the zuul configuration
porting work that we're going to do as part of the python3-first
goal, then we can take advantage of those patches to trigger doc
rebuilds in all of the projects.

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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100:
> On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  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?

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-dev] [tc] [all] TC Report 18-26

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-26.html

All the bits and pieces of OpenStack are interconnected and
interdependent across the many groupings of technology and people.
When we plan or make changes, wiggling something _here_ has
consequences over _there_. Some intended, some unintended.

This is such commonly accepted wisdom that to say it risks being a
cliche but acting accordingly remains hard.

This
[morning](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-26.log.html#t2018-06-26T09:09:57)
Thierry and I had a useful conversation about the [Tech Vision
2018 etherpad](https://etherpad.openstack.org/p/tech-vision-2018).
One of the issues there is agreeing on what we're even talking
about. How can we have a vision for a "cloud" if we don't agree what
that is? There's hope that clarifying the vision will help unify
and direct energy, but as the discussion and the etherpad show,
there's work to do.

The lack of clarity on the vision is one of the reasons why
Adjutant's [application to be
official](https://review.openstack.org/#/c/553643/) still has [no
clear 
outcome](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-19.log.html#t2018-06-19T18:59:43).

Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
the TC's role as listener, mediator, and influencer lacks
definition.

Zane wrote up a blog post explaining the various ways in which the
OpenStack Foundation is 
[expanding](https://www.zerobanana.com/archive/2018/06/14#osf-expansion).
But this raises
[questions](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-20.log.html#t2018-06-20T15:41:41)
about what, if any, role the TC has in that expansion. It appears
that the board has decided to not to do a [joint leadership
meeting](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-21.log.html#t2018-06-21T16:32:17)
at the PTG, which means discussions about such things will need to
happen in other media, or be delayed until the next summit in
Berlin.

To make up for the gap, the TC is
[planning](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-21.log.html#t2018-06-21T16:54:43)
to hold [a 
gathering](http://lists.openstack.org/pipermail/openstack-tc/2018-June/001510.html)
to work on some of the much needed big-picture and
shared-understanding building.

While that shared understanding is critical, we have to be sure that
it incorporates what we can hear from people who are not long-term
members of the community. In a long discussion asking if [our
tooling makes things harder for new
contributors](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-21.log.html#t2018-06-21T15:21:24)
several of us tried to make it clear that we have an incomplete
understanding about the barriers people experience, that we often
assume rather than verify, and that sometimes our interest in and
enthusiasm for making incremental progress (because if iterating in
code is good and just, perhaps it is in social groups too?) can mean
that we avoid the deeper analysis required for paradigm shifts.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Andrea Frittoli]

On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  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.

For the same reason tempest plug ins should be branchless, which is one of
the reasons that having them in the same repo as a service was an issue:
services are branched but api/integration tests should be branchless.

Andrea


> --
> Thierry Carrez (ttx)
>
> __
> 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 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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Thierry Carrez]

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 ?


--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Mehdi Abaakouk]

Hi,

I have never understood the branchless tempest thing. Making Tempest
release is a great news for me.

But about plugins... Tempest already provides a API for plugins. If you
are going to break this API, why not using stable branches and
deprecation process like any other software ?

If you do that, plugin will be informed that Tempest will soon do a
breaking change. Their can update their plugin code and raise the
minimal tempest version required to work.

Their can do that when they have times, and not because Tempest want to
release a version soon.

Also the stable branch/deprecation process is well known by the
whole community.

And this will also allow them to release a version when their want.

So I support making release of Tempest and Plugins, but do not support
a coordinated release.

Regards,

On Tue, Jun 26, 2018 at 06:18:52PM +0900, Ghanshyam Mann wrote:

Hello Everyone,

In Queens cycle,  community goal to split the Tempest Plugin has been completed 
[1] and i think almost all the projects have separate repo for tempest plugin 
[2]. Which means each tempest plugins are being separated from their project 
release model.  Few projects have started the independent release model for 
their plugins like kuryr-tempest-plugin, ironic-tempest-plugin etc [3].  I 
think neutron-tempest-plugin also planning as chatted with amotoki.

There might be some changes in Tempest which might not work with older version 
of Tempest Plugins.  For example, If I am testing any production cloud which 
has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i will be using 
Tempest and Aodh's , Congress's Tempest plugins. With Independent release model 
of each Tempest Plugins, there might be chance that the Aodh's or Congress's 
Tempest plugin versions are not compatible with latest/known Tempest versions. 
It will become hard to find the compatible tag/release of Tempest and Tempest 
Plugins or in some cases i might need to patch up the things.

During QA feedback sessions at Vancouver Summit, there was feedback to 
coordinating the release of all Tempest plugins and Tempest [4] (also amotoki 
talked to me on this as neutron-tempest-plugin is planning their first 
release). Idea is to release/tag all the Tempest plugins and Tempest together 
so that specific release/tag can be identified as compatible version of all the 
Plugins and Tempest for testing the complete stack. That way user can get to 
know what version of Tempest Plugins is compatible with what version of Tempest.

For above use case, we need some coordinated release model among Tempest and all the Tempest 
Plugins. There should be single release of all Tempest Plugins with well defined tag whenever any 
Tempest release is happening.  For Example, Tempest version 19.0.0 is to mark the "support of 
the Rocky release". When releasing the Tempest 19.0, we will release all the Tempest plugins 
also to tag the compatibility of plugins with Tempest for "support of the Rocky release".

One way to make this coordinated release (just a initial thought):
1. Release Each Tempest Plugins whenever there is any major version release of 
Tempest (like marking the support of OpenStack release in Tempest, EOL of 
OpenStack release in Tempest)
   1.1 Each plugin or Tempest can do their intermediate release of minor 
version change which are in backward compatible way.
   1.2 This coordinated Release can be started from latest Tempest Version for 
simple reading.  Like if we start this coordinated release from Tempest version 
19.0.0 then,
   each plugins will be released as 19.0.0 and so on.

Giving the above background and use case of this coordinated release,
A) I would like to ask each plugins owner if you are agree on this coordinated 
release?  If no, please give more feedback or issue we can face due to this 
coordinated release.






If we get the agreement from all Plugins then,
B) Release team or TC help to find the better model for this use case or 
improvement in  above model.

C) Once we define the release model, find out the team owning that release 
model (there are more than 40 Tempest plugins currently) .

NOTE: Till we decide the best solution for this use case, each plugins can 
do/keep doing their plugin release as per independent release model.

[1] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] https://docs.openstack.org/tempest/latest/plugin-registry.html
[3] https://github.com/openstack/kuryr-tempest-plugin/releases
  https://github.com/openstack/ironic-tempest-plugin/releases
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131011.html


-gmann


__
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


--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Dmitry Tantsur]

On 06/26/2018 11:57 AM, Ghanshyam Mann wrote:




   On Tue, 26 Jun 2018 18:37:42 +0900 Dmitry Tantsur  
wrote 
  > On 06/26/2018 11:18 AM, Ghanshyam Mann wrote:
  > > Hello Everyone,
  > >
  > > In Queens cycle,  community goal to split the Tempest Plugin has been 
completed [1] and i think almost all the projects have separate repo for tempest 
plugin [2]. Which means each tempest plugins are being separated from their project 
release model.  Few projects have started the independent release model for their 
plugins like kuryr-tempest-plugin, ironic-tempest-plugin etc [3].  I think 
neutron-tempest-plugin also planning as chatted with amotoki.
  > >
  > > There might be some changes in Tempest which might not work with older 
version of Tempest Plugins.  For example, If I am testing any production cloud which 
has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i will be using Tempest and 
Aodh's , Congress's Tempest plugins. With Independent release model of each Tempest 
Plugins, there might be chance that the Aodh's or Congress's Tempest plugin versions 
are not compatible with latest/known Tempest versions. It will become hard to find 
the compatible tag/release of Tempest and Tempest Plugins or in some cases i might 
need to patch up the things.
  >
  > FWIW this is solved by stable branches for all other projects. If we cannot 
keep
  > Tempest compatible with all supported branches, we should back off our 
decision
  > to make it branchless. The very nature of being branchless implies being
  > compatible with all supported releases.
  >
  > >
  > > During QA feedback sessions at Vancouver Summit, there was feedback to 
coordinating the release of all Tempest plugins and Tempest [4] (also amotoki talked 
to me on this as neutron-tempest-plugin is planning their first release). Idea is to 
release/tag all the Tempest plugins and Tempest together so that specific release/tag 
can be identified as compatible version of all the Plugins and Tempest for testing 
the complete stack. That way user can get to know what version of Tempest Plugins is 
compatible with what version of Tempest.
  > >
  > > For above use case, we need some coordinated release model among Tempest and all the Tempest 
Plugins. There should be single release of all Tempest Plugins with well defined tag whenever any Tempest 
release is happening.  For Example, Tempest version 19.0.0 is to mark the "support of the Rocky 
release". When releasing the Tempest 19.0, we will release all the Tempest plugins also to tag the 
compatibility of plugins with Tempest for "support of the Rocky release".
  > >
  > > One way to make this coordinated release (just a initial thought):
  > > 1. Release Each Tempest Plugins whenever there is any major version 
release of Tempest (like marking the support of OpenStack release in Tempest, EOL of 
OpenStack release in Tempest)
  > >  1.1 Each plugin or Tempest can do their intermediate release of 
minor version change which are in backward compatible way.
  > >  1.2 This coordinated Release can be started from latest Tempest 
Version for simple reading.  Like if we start this coordinated release from Tempest 
version 19.0.0 then,
  > >  each plugins will be released as 19.0.0 and so on.
  > >
  > > Giving the above background and use case of this coordinated release,
  > > A) I would like to ask each plugins owner if you are agree on this 
coordinated release?  If no, please give more feedback or issue we can face due to 
this coordinated release.
  >
  > Disclaimer: I'm not the PTL.
  >
  > Similarly to Luigi, I don't feel well about forcing a plugin release at the 
same
  > time as a tempest release, UNLESS tempest folks are going to coordinate 
their
  > releases with all how-many-do-we-have plugins. What I'd like to avoid is 
cutting
  > a release in the middle of a patch chain or some refactoring just because
  > tempest happened to have a release right now.

I understand your point. But we can avoid that case if we only coordinate on 
major version bump only. as i mentioned in 1.2 point, Tempest and Tempest 
plugins can do their intermediate release anytime which are nothing but 
backward compatible release. In this proposed model, we can do a coordinated 
release for major version bump only which is happening only on OpenStack 
release and EOL of any stable branch.


Even bigger concern: what if the plugin is actually not compatible yet? Say, 
you're releasing tempest 19.0. As the same point you're cutting 
ironic-tempest-plugin 19.0. Who guarantees that they're compatible? If we 
haven't had any patches for it in a month, it may well happen that it does not work.




Or I am all open to have another release model which can be best suited for all 
plugins which can address the mentioned use case of coordinated release.


My suggestion: tempest has to be compatible with all supported releases (of both 
services and plugins) OR be branched.




-gmann
  >
  > >
  

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Rabi Mishra]

On Tue, Jun 26, 2018 at 2:48 PM, Ghanshyam Mann 
wrote:

> Hello Everyone,
>
> In Queens cycle,  community goal to split the Tempest Plugin has been
> completed [1] and i think almost all the projects have separate repo for
> tempest plugin [2]. Which means each tempest plugins are being separated
> from their project release model.  Few projects have started the
> independent release model for their plugins like kuryr-tempest-plugin,
> ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also
> planning as chatted with amotoki.
>
> There might be some changes in Tempest which might not work with older
> version of Tempest Plugins.


I don't think that's a good premise. Isn't tempest branchless and by
definition should be backward compatible with service releases?

If there are changes in the plugin interface in tempest, I would also
expect those to be backward compatible too. Likewise plugins should be
backward compatible with their respective projects, so any kind of release
model would work.

Else, I think the whole branchless concept is of very little use.

For example, If I am testing any production cloud which has Nova, Neutron,
> Cinder, Keystone , Aodh, Congress etc  i will be using Tempest and Aodh's ,
> Congress's Tempest plugins. With Independent release model of each Tempest
> Plugins, there might be chance that the Aodh's or Congress's Tempest plugin
> versions are not compatible with latest/known Tempest versions. It will
> become hard to find the compatible tag/release of Tempest and Tempest
> Plugins or in some cases i might need to patch up the things.
>
> During QA feedback sessions at Vancouver Summit, there was feedback to
> coordinating the release of all Tempest plugins and Tempest [4] (also
> amotoki talked to me on this as neutron-tempest-plugin is planning their
> first release). Idea is to release/tag all the Tempest plugins and Tempest
> together so that specific release/tag can be identified as compatible
> version of all the Plugins and Tempest for testing the complete stack. That
> way user can get to know what version of Tempest Plugins is compatible with
> what version of Tempest.
>
> For above use case, we need some coordinated release model among Tempest
> and all the Tempest Plugins. There should be single release of all Tempest
> Plugins with well defined tag whenever any Tempest release is happening.
> For Example, Tempest version 19.0.0 is to mark the "support of the Rocky
> release". When releasing the Tempest 19.0, we will release all the Tempest
> plugins also to tag the compatibility of plugins with Tempest for "support
> of the Rocky release".
>
> One way to make this coordinated release (just a initial thought):
> 1. Release Each Tempest Plugins whenever there is any major version
> release of Tempest (like marking the support of OpenStack release in
> Tempest, EOL of OpenStack release in Tempest)
> 1.1 Each plugin or Tempest can do their intermediate release of minor
> version change which are in backward compatible way.
> 1.2 This coordinated Release can be started from latest Tempest
> Version for simple reading.  Like if we start this coordinated release from
> Tempest version 19.0.0 then,
> each plugins will be released as 19.0.0 and so on.
>
> Giving the above background and use case of this coordinated release,
> A) I would like to ask each plugins owner if you are agree on this
> coordinated release?  If no, please give more feedback or issue we can face
> due to this coordinated release.
>
> If we get the agreement from all Plugins then,
> B) Release team or TC help to find the better model for this use case or
> improvement in  above model.
>
> C) Once we define the release model, find out the team owning that release
> model (there are more than 40 Tempest plugins currently) .
>
> NOTE: Till we decide the best solution for this use case, each plugins can
> do/keep doing their plugin release as per independent release model.
>
> [1] https://governance.openstack.org/tc/goals/queens/split-tempe
> st-plugins.html
> [2] https://docs.openstack.org/tempest/latest/plugin-registry.html
> [3] https://github.com/openstack/kuryr-tempest-plugin/releases
>https://github.com/openstack/ironic-tempest-plugin/releases
> [4] http://lists.openstack.org/pipermail/openstack-dev/2018-June
> /131011.html
>
>
> -gmann
>
>
> __
> 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
>



-- 
Regards,
Rabi Mishra
__
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

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Luigi Toscano]

On Tuesday, 26 June 2018 11:52:53 CEST Ghanshyam Mann wrote:
>   On Tue, 26 Jun 2018 18:28:03 +0900 Luigi Toscano 
> wrote 
>  > On Tuesday, 26 June 2018 11:18:52 CEST Ghanshyam Mann wrote:
>  > > Hello Everyone,
>  > > 
>  > > In Queens cycle,  community goal to split the Tempest Plugin has been
>  > > completed [1] and i think almost all the projects have separate repo
>  > > for
>  > > tempest plugin [2]. Which means each tempest plugins are being
>  > > separated
>  > > from their project release model.  Few projects have started the
>  > > independent release model for their plugins like kuryr-tempest-plugin,
>  > > ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also
>  > > planning as chatted with amotoki.
>  > > 
>  > > There might be some changes in Tempest which might not work with older
>  > > version of Tempest Plugins.  For example, If I am testing any
>  > > production
>  > > cloud which has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i
>  > > will be using Tempest and Aodh's , Congress's Tempest plugins. With
>  > > Independent release model of each Tempest Plugins, there might be
>  > > chance
>  > > that the Aodh's or Congress's Tempest plugin versions are not
>  > > compatible
>  > > with latest/known Tempest versions. It will become hard to find the
>  > > compatible tag/release of Tempest and Tempest Plugins or in some cases
>  > > i
>  > > might need to patch up the things.
>  > > 
>  > > During QA feedback sessions at Vancouver Summit, there was feedback to
>  > > coordinating the release of all Tempest plugins and Tempest [4] (also
>  > > amotoki talked to me on this as neutron-tempest-plugin is planning
>  > > their
>  > > first release). Idea is to release/tag all the Tempest plugins and
>  > > Tempest
>  > > together so that specific release/tag can be identified as compatible
>  > > version of all the Plugins and Tempest for testing the complete stack.
>  > > That
>  > > way user can get to know what version of Tempest Plugins is compatible
>  > > with
>  > > what version of Tempest.
>  > > 
>  > > For above use case, we need some coordinated release model among
>  > > Tempest and all the Tempest Plugins. There should be single release of
>  > > all Tempest Plugins with well defined tag whenever any Tempest release
>  > > is happening. For Example, Tempest version 19.0.0 is to mark the
>  > > "support of the Rocky release". When releasing the Tempest 19.0, we
>  > > will release all the Tempest plugins also to tag the compatibility of
>  > > plugins with Tempest for "support of the Rocky release".
>  > > 
>  > > One way to make this coordinated release (just a initial thought):
>  > > 1. Release Each Tempest Plugins whenever there is any major version
>  > > release
>  > > of Tempest (like marking the support of OpenStack release in Tempest,
>  > > EOL
>  > > of OpenStack release in Tempest) 1.1 Each plugin or Tempest can do
>  > > their
>  > > intermediate release of minor version change which are in backward
>  > > compatible way. 1.2 This coordinated Release can be started from latest
>  > > Tempest Version for simple reading.  Like if we start this coordinated
>  > > release from Tempest version 19.0.0 then, each plugins will be released
>  > > as
>  > > 19.0.0 and so on.
>  > > 
>  > > Giving the above background and use case of this coordinated release,
>  > > A) I would like to ask each plugins owner if you are agree on this
>  > > coordinated release?  If no, please give more feedback or issue we can
>  > > face
>  > > due to this coordinated release.
>  > 
>  > The Sahara PTL may disagree with me, but I disagree with forcing each
>  > team to release in a coordinate model.
>  > 
>  > I already take care of releasing sahara-tests, which contains both the
>  > tempest plugin and the scenario tests, when a new major version of
>  > OpenStack is released, keeping the compatibility with the relevant
>  > versions of Tempest.
>  > 
>  > tl;dr I agree with having Tempest plugins follow the same lifecycle of
>  > Tempest, but please allow me to do so manually.
> 
> But with coordinated release,  we can make sure we have particular tags
> which can be used in OpenStack Complete testing. With independent release
> model, there is no guarantee that all tempest plugins will be compatible
> with Tempest versions.

With the independent release model (in general, not just for Tempest plugins) 
it's up to the program maintainer to ensure that things are compatible. 
Let me make sure that:
- I agree that Tempest plugins should follow the same lifecycle than Tempest. 
It's the policy that I applied for the Tempest plugin part of sahara-tests 
since Kilo.
- most of plugins maintainer don't care, can't care or shouldn't care about 
the release process: then coordinated release is fine (as it happen also for 
the general usage of coordinated release vs independent relase in OpenStack)
- I still prefer to manage this myself, because the repository does not 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Tue, 26 Jun 2018 18:37:42 +0900 Dmitry Tantsur  
wrote  
 > On 06/26/2018 11:18 AM, Ghanshyam Mann wrote:
 > > Hello Everyone,
 > > 
 > > In Queens cycle,  community goal to split the Tempest Plugin has been 
 > > completed [1] and i think almost all the projects have separate repo for 
 > > tempest plugin [2]. Which means each tempest plugins are being separated 
 > > from their project release model.  Few projects have started the 
 > > independent release model for their plugins like kuryr-tempest-plugin, 
 > > ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also 
 > > planning as chatted with amotoki.
 > > 
 > > There might be some changes in Tempest which might not work with older 
 > > version of Tempest Plugins.  For example, If I am testing any production 
 > > cloud which has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i 
 > > will be using Tempest and Aodh's , Congress's Tempest plugins. With 
 > > Independent release model of each Tempest Plugins, there might be chance 
 > > that the Aodh's or Congress's Tempest plugin versions are not compatible 
 > > with latest/known Tempest versions. It will become hard to find the 
 > > compatible tag/release of Tempest and Tempest Plugins or in some cases i 
 > > might need to patch up the things.
 > 
 > FWIW this is solved by stable branches for all other projects. If we cannot 
 > keep 
 > Tempest compatible with all supported branches, we should back off our 
 > decision 
 > to make it branchless. The very nature of being branchless implies being 
 > compatible with all supported releases.
 > 
 > > 
 > > During QA feedback sessions at Vancouver Summit, there was feedback to 
 > > coordinating the release of all Tempest plugins and Tempest [4] (also 
 > > amotoki talked to me on this as neutron-tempest-plugin is planning their 
 > > first release). Idea is to release/tag all the Tempest plugins and Tempest 
 > > together so that specific release/tag can be identified as compatible 
 > > version of all the Plugins and Tempest for testing the complete stack. 
 > > That way user can get to know what version of Tempest Plugins is 
 > > compatible with what version of Tempest.
 > > 
 > > For above use case, we need some coordinated release model among Tempest 
 > > and all the Tempest Plugins. There should be single release of all Tempest 
 > > Plugins with well defined tag whenever any Tempest release is happening.  
 > > For Example, Tempest version 19.0.0 is to mark the "support of the Rocky 
 > > release". When releasing the Tempest 19.0, we will release all the Tempest 
 > > plugins also to tag the compatibility of plugins with Tempest for "support 
 > > of the Rocky release".
 > > 
 > > One way to make this coordinated release (just a initial thought):
 > > 1. Release Each Tempest Plugins whenever there is any major version 
 > > release of Tempest (like marking the support of OpenStack release in 
 > > Tempest, EOL of OpenStack release in Tempest)
 > >  1.1 Each plugin or Tempest can do their intermediate release of minor 
 > > version change which are in backward compatible way.
 > >  1.2 This coordinated Release can be started from latest Tempest 
 > > Version for simple reading.  Like if we start this coordinated release 
 > > from Tempest version 19.0.0 then,
 > >  each plugins will be released as 19.0.0 and so on.
 > > 
 > > Giving the above background and use case of this coordinated release,
 > > A) I would like to ask each plugins owner if you are agree on this 
 > > coordinated release?  If no, please give more feedback or issue we can 
 > > face due to this coordinated release.
 > 
 > Disclaimer: I'm not the PTL.
 > 
 > Similarly to Luigi, I don't feel well about forcing a plugin release at the 
 > same 
 > time as a tempest release, UNLESS tempest folks are going to coordinate 
 > their 
 > releases with all how-many-do-we-have plugins. What I'd like to avoid is 
 > cutting 
 > a release in the middle of a patch chain or some refactoring just because 
 > tempest happened to have a release right now.

I understand your point. But we can avoid that case if we only coordinate on 
major version bump only. as i mentioned in 1.2 point, Tempest and Tempest 
plugins can do their intermediate release anytime which are nothing but 
backward compatible release. In this proposed model, we can do a coordinated 
release for major version bump only which is happening only on OpenStack 
release and EOL of any stable branch. 

Or I am all open to have another release model which can be best suited for all 
plugins which can address the mentioned use case of coordinated release. 

-gmann
 > 
 > > 
 > > If we get the agreement from all Plugins then,
 > > B) Release team or TC help to find the better model for this use case or 
 > > improvement in  above model.
 > > 
 > > C) Once we define the release model, find out the team owning that release 
 > > model (there are more than 40 Tempest plugins 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

  On Tue, 26 Jun 2018 18:28:03 +0900 Luigi Toscano  
wrote  
 > On Tuesday, 26 June 2018 11:18:52 CEST Ghanshyam Mann wrote: 
 > > Hello Everyone, 
 > >  
 > > In Queens cycle,  community goal to split the Tempest Plugin has been 
 > > completed [1] and i think almost all the projects have separate repo for 
 > > tempest plugin [2]. Which means each tempest plugins are being separated 
 > > from their project release model.  Few projects have started the 
 > > independent release model for their plugins like kuryr-tempest-plugin, 
 > > ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also 
 > > planning as chatted with amotoki. 
 > >  
 > > There might be some changes in Tempest which might not work with older 
 > > version of Tempest Plugins.  For example, If I am testing any production 
 > > cloud which has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i 
 > > will be using Tempest and Aodh's , Congress's Tempest plugins. With 
 > > Independent release model of each Tempest Plugins, there might be chance 
 > > that the Aodh's or Congress's Tempest plugin versions are not compatible 
 > > with latest/known Tempest versions. It will become hard to find the 
 > > compatible tag/release of Tempest and Tempest Plugins or in some cases i 
 > > might need to patch up the things. 
 > >  
 > > During QA feedback sessions at Vancouver Summit, there was feedback to 
 > > coordinating the release of all Tempest plugins and Tempest [4] (also 
 > > amotoki talked to me on this as neutron-tempest-plugin is planning their 
 > > first release). Idea is to release/tag all the Tempest plugins and Tempest 
 > > together so that specific release/tag can be identified as compatible 
 > > version of all the Plugins and Tempest for testing the complete stack. 
 > > That 
 > > way user can get to know what version of Tempest Plugins is compatible 
 > > with 
 > > what version of Tempest. 
 > >  
 > > For above use case, we need some coordinated release model among Tempest 
 > > and 
 > > all the Tempest Plugins. There should be single release of all Tempest 
 > > Plugins with well defined tag whenever any Tempest release is happening.  
 > > For Example, Tempest version 19.0.0 is to mark the "support of the Rocky 
 > > release". When releasing the Tempest 19.0, we will release all the Tempest 
 > > plugins also to tag the compatibility of plugins with Tempest for "support 
 > > of the Rocky release". 
 > >  
 > > One way to make this coordinated release (just a initial thought): 
 > > 1. Release Each Tempest Plugins whenever there is any major version 
 > > release 
 > > of Tempest (like marking the support of OpenStack release in Tempest, EOL 
 > > of OpenStack release in Tempest) 1.1 Each plugin or Tempest can do their 
 > > intermediate release of minor version change which are in backward 
 > > compatible way. 1.2 This coordinated Release can be started from latest 
 > > Tempest Version for simple reading.  Like if we start this coordinated 
 > > release from Tempest version 19.0.0 then, each plugins will be released as 
 > > 19.0.0 and so on. 
 > >  
 > > Giving the above background and use case of this coordinated release, 
 > > A) I would like to ask each plugins owner if you are agree on this 
 > > coordinated release?  If no, please give more feedback or issue we can 
 > > face 
 > > due to this coordinated release. 
 > >  
 >  
 > The Sahara PTL may disagree with me, but I disagree with forcing each team 
 > to  
 > release in a coordinate model. 
 >  
 > I already take care of releasing sahara-tests, which contains both the 
 > tempest  
 > plugin and the scenario tests, when a new major version of OpenStack is  
 > released, keeping the compatibility with the relevant versions of Tempest. 
 >  
 > tl;dr I agree with having Tempest plugins follow the same lifecycle of  
 > Tempest, but please allow me to do so manually. 

But with coordinated release,  we can make sure we have particular tags which 
can be used in OpenStack Complete testing. With independent release model, 
there is no guarantee that all tempest plugins will be compatible with Tempest 
versions. 

-gmann  

 >  
 >  
 > --  
 > Luigi 
 >  
 >  
 > 



__
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

Re: [openstack-dev] [cinder] making volume available without stopping VM

[Volodymyr Litovka]

Hi Sean,

thanks for the responce, my questions and comments below.

On 6/25/18 9:42 PM, Sean McGinnis wrote:


Not sure if it's an option for you, but in the Pike release support was added
to be able to extend attached volumes. There are several caveats with this
feature though. I believe it only works with libvirt, and if I remember right,
only newer versions of libvirt. You need to have notifications working for Nova
to pick up that Cinder has extended the volume.
Pike release notes states the following: "It is now possible to signal 
and perform an online volume size change as of the 2.51 microversion 
using the volume-extended external event. Nova will perform the volume 
extension so the host can detect its new size. It will also resize the 
device in QEMU so instance can detect the new disk size without 
rebooting. Currently only the *libvirt compute driver with iSCSI and FC 
volumes supports the online volume size change*." And yes, it doesn't 
work for me since I'm using CEPH as backend.


Queens release notes says nothing on changes. Feature matrix 
(https://docs.openstack.org/nova/queens/user/support-matrix.html) says 
it's supported on libvirt/x86 without any other further details. Does 
anybody know whether this feature implemented in Queens for other 
backends except iSCSI and FC?


Mentioned earlier spec are talking about how to make result of resize to 
be visible to VM immediately upon resize, without restarting VM, while I 
don't asking for this. My question is how to resize volume and make it 
available after restart, see below



In fact, I'm ok with delayed resize (upon power-cycle), and it's not an
issue for me that VM don't detect changes immediately. What I want to
understand is that changes to Cinder (and, thus, underlying changes to CEPH)
are safe for VM while it's in active state.

No, this is not considered safe. You are forcing the volume state to be
availabile when it is in fact not.


In very general case, I agree with you. For example, I can imagine that 
allocation of new blocks can fail if volume is declared as available, 
but, in particular case of CEPH:


- in short:
# status of volume in Cinder means nothing to CEPH

- in details:
# while Cinder do provisioning and maintenance
# kvm/libvirt work directly with CEPH (after got this endpoint from 
<-Nova<-Cinder)
# and I see no changes in CEPH's status of volume while it is available 
in Cinder:


* in-use:
$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':
    size 20480 MB in 5120 objects
    order 22 (4096 kB objects)
    block_name_prefix: rbd_data.2414a7572c9f46
    format: 2
    features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
    flags:
    create_timestamp: Mon Jun 25 10:47:03 2018
    parent: 
volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap

    overlap: 3072 MB

* available:
$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':
    size 20480 MB in 5120 objects
    order 22 (4096 kB objects)
    block_name_prefix: rbd_data.2414a7572c9f46
    format: 2
    features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
    flags:
    create_timestamp: Mon Jun 25 10:47:03 2018
    parent: 
volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap

    overlap: 3072 MB

# and, during copying data, CEPH successfully allocates additional 
blocks to the volume:


* before copying (volume is already available in Cinder)
$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
NAME    PROVISIONED USED
volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb  20480M *2256M*

* after copying (while volume is available in Cinder)
$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
NAME    PROVISIONED USED
volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb  20480M *2560M*

# which preserved after back to in-use:
$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
NAME    PROVISIONED USED
volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb  20480M *2560M*
$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb
rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':
    size 20480 MB in 5120 objects
    order 22 (4096 kB objects)
    block_name_prefix: rbd_data.2414a7572c9f46
    format: 2
    features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
    flags:
    create_timestamp: Mon Jun 25 10:47:03 2018
    parent: 
volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap

    overlap: 3072 MB

Actually, the only problem with safety I see is possible administrative 
race - since volume is available, cloud administrator or any kind of 
automation can break dependencies. 

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Dmitry Tantsur]

On 06/26/2018 11:18 AM, Ghanshyam Mann wrote:

Hello Everyone,

In Queens cycle,  community goal to split the Tempest Plugin has been completed 
[1] and i think almost all the projects have separate repo for tempest plugin 
[2]. Which means each tempest plugins are being separated from their project 
release model.  Few projects have started the independent release model for 
their plugins like kuryr-tempest-plugin, ironic-tempest-plugin etc [3].  I 
think neutron-tempest-plugin also planning as chatted with amotoki.

There might be some changes in Tempest which might not work with older version 
of Tempest Plugins.  For example, If I am testing any production cloud which 
has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i will be using 
Tempest and Aodh's , Congress's Tempest plugins. With Independent release model 
of each Tempest Plugins, there might be chance that the Aodh's or Congress's 
Tempest plugin versions are not compatible with latest/known Tempest versions. 
It will become hard to find the compatible tag/release of Tempest and Tempest 
Plugins or in some cases i might need to patch up the things.


FWIW this is solved by stable branches for all other projects. If we cannot keep 
Tempest compatible with all supported branches, we should back off our decision 
to make it branchless. The very nature of being branchless implies being 
compatible with all supported releases.




During QA feedback sessions at Vancouver Summit, there was feedback to 
coordinating the release of all Tempest plugins and Tempest [4] (also amotoki 
talked to me on this as neutron-tempest-plugin is planning their first 
release). Idea is to release/tag all the Tempest plugins and Tempest together 
so that specific release/tag can be identified as compatible version of all the 
Plugins and Tempest for testing the complete stack. That way user can get to 
know what version of Tempest Plugins is compatible with what version of Tempest.

For above use case, we need some coordinated release model among Tempest and all the Tempest 
Plugins. There should be single release of all Tempest Plugins with well defined tag whenever any 
Tempest release is happening.  For Example, Tempest version 19.0.0 is to mark the "support of 
the Rocky release". When releasing the Tempest 19.0, we will release all the Tempest plugins 
also to tag the compatibility of plugins with Tempest for "support of the Rocky release".

One way to make this coordinated release (just a initial thought):
1. Release Each Tempest Plugins whenever there is any major version release of 
Tempest (like marking the support of OpenStack release in Tempest, EOL of 
OpenStack release in Tempest)
 1.1 Each plugin or Tempest can do their intermediate release of minor 
version change which are in backward compatible way.
 1.2 This coordinated Release can be started from latest Tempest Version 
for simple reading.  Like if we start this coordinated release from Tempest 
version 19.0.0 then,
 each plugins will be released as 19.0.0 and so on.

Giving the above background and use case of this coordinated release,
A) I would like to ask each plugins owner if you are agree on this coordinated 
release?  If no, please give more feedback or issue we can face due to this 
coordinated release.


Disclaimer: I'm not the PTL.

Similarly to Luigi, I don't feel well about forcing a plugin release at the same 
time as a tempest release, UNLESS tempest folks are going to coordinate their 
releases with all how-many-do-we-have plugins. What I'd like to avoid is cutting 
a release in the middle of a patch chain or some refactoring just because 
tempest happened to have a release right now.




If we get the agreement from all Plugins then,
B) Release team or TC help to find the better model for this use case or 
improvement in  above model.

C) Once we define the release model, find out the team owning that release 
model (there are more than 40 Tempest plugins currently) .

NOTE: Till we decide the best solution for this use case, each plugins can 
do/keep doing their plugin release as per independent release model.

[1] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] https://docs.openstack.org/tempest/latest/plugin-registry.html
[3] https://github.com/openstack/kuryr-tempest-plugin/releases
https://github.com/openstack/ironic-tempest-plugin/releases
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131011.html


-gmann


__
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Luigi Toscano]

On Tuesday, 26 June 2018 11:18:52 CEST Ghanshyam Mann wrote:
> Hello Everyone,
> 
> In Queens cycle,  community goal to split the Tempest Plugin has been
> completed [1] and i think almost all the projects have separate repo for
> tempest plugin [2]. Which means each tempest plugins are being separated
> from their project release model.  Few projects have started the
> independent release model for their plugins like kuryr-tempest-plugin,
> ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also
> planning as chatted with amotoki.
> 
> There might be some changes in Tempest which might not work with older
> version of Tempest Plugins.  For example, If I am testing any production
> cloud which has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i
> will be using Tempest and Aodh's , Congress's Tempest plugins. With
> Independent release model of each Tempest Plugins, there might be chance
> that the Aodh's or Congress's Tempest plugin versions are not compatible
> with latest/known Tempest versions. It will become hard to find the
> compatible tag/release of Tempest and Tempest Plugins or in some cases i
> might need to patch up the things.
> 
> During QA feedback sessions at Vancouver Summit, there was feedback to
> coordinating the release of all Tempest plugins and Tempest [4] (also
> amotoki talked to me on this as neutron-tempest-plugin is planning their
> first release). Idea is to release/tag all the Tempest plugins and Tempest
> together so that specific release/tag can be identified as compatible
> version of all the Plugins and Tempest for testing the complete stack. That
> way user can get to know what version of Tempest Plugins is compatible with
> what version of Tempest.
> 
> For above use case, we need some coordinated release model among Tempest and
> all the Tempest Plugins. There should be single release of all Tempest
> Plugins with well defined tag whenever any Tempest release is happening. 
> For Example, Tempest version 19.0.0 is to mark the "support of the Rocky
> release". When releasing the Tempest 19.0, we will release all the Tempest
> plugins also to tag the compatibility of plugins with Tempest for "support
> of the Rocky release".
> 
> One way to make this coordinated release (just a initial thought):
> 1. Release Each Tempest Plugins whenever there is any major version release
> of Tempest (like marking the support of OpenStack release in Tempest, EOL
> of OpenStack release in Tempest) 1.1 Each plugin or Tempest can do their
> intermediate release of minor version change which are in backward
> compatible way. 1.2 This coordinated Release can be started from latest
> Tempest Version for simple reading.  Like if we start this coordinated
> release from Tempest version 19.0.0 then, each plugins will be released as
> 19.0.0 and so on.
> 
> Giving the above background and use case of this coordinated release,
> A) I would like to ask each plugins owner if you are agree on this
> coordinated release?  If no, please give more feedback or issue we can face
> due to this coordinated release.
> 

The Sahara PTL may disagree with me, but I disagree with forcing each team to 
release in a coordinate model.

I already take care of releasing sahara-tests, which contains both the tempest 
plugin and the scenario tests, when a new major version of OpenStack is 
released, keeping the compatibility with the relevant versions of Tempest.

tl;dr I agree with having Tempest plugins follow the same lifecycle of 
Tempest, but please allow me to do so manually.


-- 
Luigi



__
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-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Ghanshyam Mann]

Hello Everyone,

In Queens cycle,  community goal to split the Tempest Plugin has been completed 
[1] and i think almost all the projects have separate repo for tempest plugin 
[2]. Which means each tempest plugins are being separated from their project 
release model.  Few projects have started the independent release model for 
their plugins like kuryr-tempest-plugin, ironic-tempest-plugin etc [3].  I 
think neutron-tempest-plugin also planning as chatted with amotoki. 

There might be some changes in Tempest which might not work with older version 
of Tempest Plugins.  For example, If I am testing any production cloud which 
has Nova, Neutron, Cinder, Keystone , Aodh, Congress etc  i will be using 
Tempest and Aodh's , Congress's Tempest plugins. With Independent release model 
of each Tempest Plugins, there might be chance that the Aodh's or Congress's 
Tempest plugin versions are not compatible with latest/known Tempest versions. 
It will become hard to find the compatible tag/release of Tempest and Tempest 
Plugins or in some cases i might need to patch up the things. 

During QA feedback sessions at Vancouver Summit, there was feedback to 
coordinating the release of all Tempest plugins and Tempest [4] (also amotoki 
talked to me on this as neutron-tempest-plugin is planning their first 
release). Idea is to release/tag all the Tempest plugins and Tempest together 
so that specific release/tag can be identified as compatible version of all the 
Plugins and Tempest for testing the complete stack. That way user can get to 
know what version of Tempest Plugins is compatible with what version of 
Tempest. 

For above use case, we need some coordinated release model among Tempest and 
all the Tempest Plugins. There should be single release of all Tempest Plugins 
with well defined tag whenever any Tempest release is happening.  For Example, 
Tempest version 19.0.0 is to mark the "support of the Rocky release". When 
releasing the Tempest 19.0, we will release all the Tempest plugins also to tag 
the compatibility of plugins with Tempest for "support of the Rocky release". 

One way to make this coordinated release (just a initial thought):
1. Release Each Tempest Plugins whenever there is any major version release of 
Tempest (like marking the support of OpenStack release in Tempest, EOL of 
OpenStack release in Tempest)
1.1 Each plugin or Tempest can do their intermediate release of minor 
version change which are in backward compatible way.
1.2 This coordinated Release can be started from latest Tempest Version for 
simple reading.  Like if we start this coordinated release from Tempest version 
19.0.0 then, 
each plugins will be released as 19.0.0 and so on.

Giving the above background and use case of this coordinated release,
A) I would like to ask each plugins owner if you are agree on this coordinated 
release?  If no, please give more feedback or issue we can face due to this 
coordinated release. 

If we get the agreement from all Plugins then, 
B) Release team or TC help to find the better model for this use case or 
improvement in  above model. 

C) Once we define the release model, find out the team owning that release 
model (there are more than 40 Tempest plugins currently) . 

NOTE: Till we decide the best solution for this use case, each plugins can 
do/keep doing their plugin release as per independent release model. 

[1] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] https://docs.openstack.org/tempest/latest/plugin-registry.html
[3] https://github.com/openstack/kuryr-tempest-plugin/releases 
   https://github.com/openstack/ironic-tempest-plugin/releases 
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131011.html 


-gmann


__
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