Description of problem: Deleting BC in web console after upgrade cannot delete build triggered before upgrade (DC and its RC have no the problem). As comparison (notice the ** words): Deleting BC in web console after upgrade **CAN** delete build that was triggered **AFTER** upgrade. Deleting BC in **CLI** after upgrade **CAN** delete build that was triggered before upgrade Not sure if the issue relates to https://trello.com/c/mZuAqafi/581-2-cascading-deletes-in-web-console-evg-usability-kubernetes Version-Release number of selected component (if applicable): openshift v3.6.152 How reproducible: Always Steps to Reproduce: 1. Before upgrade 3.5 to 3.6, create project, BC $ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git # will trigger build ruby-ex-1 $ oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json # trigger build ruby-sample-build-1 2. After upgrade to 3.6, login to web console --> Builds --> ruby-ex, click Start Build several times Then click Actions --> Delete --> Delete (confirm) 3. Check the build 4. As comparison, repeat steps 2 ~ 3, but this time use CLI to delete BC ruby-sample-build Actual results: 3. Deleting BC in web console can delete build triggered after upgrade, but does not delete the one triggered before upgrade. Can still see it in CLI/web $ oc get build | grep ruby-ex ruby-ex-1 Source Git@855ab2d Complete 26 hours ago 58s 4. ruby-sample-build-1 was before upgrade, ruby-sample-build-2 was after upgrade. Both can be deleted in CLI deleting bc ruby-sample-build $ oc get build | grep ruby-sample-build ruby-sample-build-1 Source Git@022d87e Complete 26 hours ago 21s ruby-sample-build-2 Source Git@022d87e Complete About an hour ago 36s $ oc delete bc ruby-sample-build $ oc get build | grep ruby-sample-build # get empty output Expected results: 3. Deleting BC in web console can delete all builds no matter triggered before/after upgrade Additional info: Description of problem: Version-Release number of the following components: rpm -q openshift-ansible rpm -q ansible ansible --version How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Please include the entire output from the last TASK line through the end of output if an error is generated Expected results: Additional info: Please attach logs from ansible-playbook with the -vvv flag
Please ignore the content after the 1st "Additional info:" in comment 0. I didn't notice/know why it was there when "New" the bug.
I think this is working as expected. The builds before the update do not have ownerrefs to their bc, so they are not cleaned up by garbage collection. Builds after the update do, so they are. The CLI implements cascading delete on the client side, so it will clean up the builds when the BC is deleted, regardless. I guess the web console removed their cascading delete as part of the upgrade, deciding to rely on GC alone? What i'm not sure of is: 1) was it expected that we would do a migration to add ownerrefs to the build? 2) was it expected that the web console would retain the client side cascading logic like the CLI did, until we get further down the road? 3) Why are DCs behaving differently (did they do (1) or (2)?)
Answering (2) and (3): (2) The web console relies solely on garbage collection (foreground propagation) for cascading. We've never had client side logic for it, and builds were orphaned in 3.5. (3) The controller adds in owner refers to existing RCs owned by the DC after upgrade, so cascade works. I'll leave (1) for Clayton :)
Given the availability of workarounds (just go delete the older builds like you did in 3.5) it doesn't seem likely we're going to introduce a migration for this.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days