Open Stack

Thanks for response.
My recommendation is:
1. only allow patches into openstack/ironic-tempest-plugin
2. Give Ironic CI owners time period (3 weeks?) to switch their setup to only use openstack/ironic-tempest-plugin and not master and report back to Ironic CI team if it works for them. If yes, go ahead and switch if not, report back.
3. At the end of that time, if majority of Ironic CI site complete their  transition to ironic-tempest-plugin we switch.

Thanks,
Arkady


-----Original Message-----
From: Matthew Treinish [mailto:mtreinish at kortar.org] 
Sent: Monday, December 18, 2017 2:50 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

On Mon, Dec 18, 2017 at 01:37:13PM -0700, Julia Kreger wrote:
> > And actually I almost think the holiday time is the best time since 
> > the fewest number of people are going to care. But maybe I'm wrong. 
> > I do wonder if nobody is around to watch a 3rd Party CI for two 
> > weeks, how likely is it to still be working when they get back?
> >
> > I'm not vehemently opposed to delaying, but somewhat opposed.
> >
> > Thoughts?
> 
> I agree and disagree of course. :)  Arkady raises a good point about 
> availability of people, and the simple fact is they will be broken if 
> nobody is around to fix them. That being said, the true measurement is 
> going to be if third party CI shows the commits to remove the folders 
> as passing. If they pass, ideally we should proceed with removing them 
> sooner rather than later to avoid confusion. If they break after the 
> removal of the folders but still ultimately due to the removal of the 
> folders, we have found a bug that will need to be corrected, and we 
> can always temporarily revert to restore the folders in the mean time 
> until people return.
> 

Well it depends, there might not be a failure mode with removing the in-tree plugins. It depends on the test selection the 3rd party ci's run. (or if they're doing anything extra downstream which has a hard dependency on the in-tree stuff, like importing from it directly) If they're running anything from tempest itself it's unlikely they'd fail because of the plugin removal. The plugins are loaded dynamically during test discovery, and if you remove a plugin then it just doesn't get loaded by tempest anymore. So for the normal case this would only cause a failure if the only tests being selected were in the plugin (and then it fails because no tests were run).

-Matt Treinish