Description of problem: This doesn't happen very often, but occasionally teardown will fail to fully undefine the libvirt network used for a CI job. This is bad because further network devices that are leased that subnet will fail to create a cluster, leaving that lease completely broken until someone manually intervenes. This seems to be happening far more often with 4.6. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Jeremy, which Target Release are you targeting for this bug (4.6 or 4.7)? Currently it is considered "Untriaged" and it would be great if we can provide a target release.
Hi Jeremy, one more logistics question - will this bug be resolved before the end of this Sprint (October 3rd)? If not, can we add "UpcomingSprint"?
Hi Dan - very unlikely to be resolved this week. We're still in the monitoring phase to determine what causes the underlying problem, so I have added the UpcomingSprint label.
Adding "UpcomingSprint" tag as Jeremy is OOTO and this bug is unlikely to be resolved before the end of this Sprint (Oct 24th)
Hi Jeremy, will this bug be resolved before the end of this sprint (Nov 14th)? If not, can we add "UpcomingSprint"?
There isn't a clear path forward on how to fix this yet, but this will likely be targeted for post step-registry migration.
Hi Jeremy, will this bug be resolved before the end of this sprint (Dec 5th)? If not, can we add "UpcomingSprint"?
This is affected by the work that Deep is doing with the step registry migration. I don't think it will make it into next sprint, but I can see it becoming higher priority once we knock out some of the major stability improvements. Marking this "UpcomingSprint"
Hi Jeremy, I am doing this exercise one week early because most people are out next week. 1. Do you think this bug will be resolved before the end of this sprint (December 26th)? If not, I'd like to add "UpcomingSprint" 2. Do you think this bug's Target Release is still 4.7.0? If it does not target 4.7, can we set it to blank value "---"?
Adding upcomingSprint and setting the delivery to blank. I did have a conversation with the test platform team about this bug, but right now it reminds lower priority than all our other work. https://coreos.slack.com/archives/CBN38N3MW/p1608140054245400
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633