Bug 1472670 - [Upgrade] Deleting BC in web console after upgrade cannot delete build triggered before upgrade [NEEDINFO]
[Upgrade] Deleting BC in web console after upgrade cannot delete build trigge...
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build (Show other bugs)
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Ben Parees
Wenjing Zheng
Depends On:
  Show dependency treegraph
Reported: 2017-07-19 03:49 EDT by Xingxing Xia
Modified: 2017-07-27 00:22 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-27 00:22:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bparees: needinfo? (ccoleman)

Attachments (Terms of Use)

  None (edit)
Description Xingxing Xia 2017-07-19 03:49:21 EDT
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:

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:

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
Comment 1 Xingxing Xia 2017-07-19 03:54:13 EDT
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.
Comment 2 Ben Parees 2017-07-19 09:01:54 EDT
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)?)
Comment 3 Samuel Padgett 2017-07-19 09:35:54 EDT
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 :)
Comment 4 Ben Parees 2017-07-27 00:22:21 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.