Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171218/3e5aceca/attachment.sig>