Bug 1549448

There's nothing magic about those resources with respect to deletion, I seem to recall another bug related to inability to delete resources, hopefully the master team has a theory/recollection.

ah. I see what is happening.  The BC is being recreated after it is deleted.  This is likely the sync plugin.

Gabe, this is part of what i was afraid of w/ doing two-way sync between openshift and jenkins build definitions.  I thought we had an annotation that told us whether the buildconfig originated in openshift or jenkins, so we wouldn't have this problem?  (We should recognize the jenkins job was created based on a buildconfig defined in openshift, thus when then openshift buildconfig is deleted, we should not recreate the buildconfig in openshift based on the jenkins job..in fact we should be deleting the jenkins job)

Disclaimer, I'm not dismissing Ben's concerns when I note this (in fact, I think this is a validation of them, as there are some many moving parts and dependencies here).  

Turns out Jenkins calls the onUpdated callback when a deletion occurs in addition in addition to the onDeleted callback.

See this portion of some stack trace debug I added:

	at io.fabric8.jenkins.openshiftsync.PipelineJobListener.onUpdated(PipelineJobListener.java:99)
	at hudson.model.listeners.ItemListener$3.apply(ItemListener.java:229)
	at hudson.model.listeners.ItemListener$3.apply(ItemListener.java:227)
	at hudson.model.listeners.ItemListener.forAll(ItemListener.java:180)
	at hudson.model.listeners.ItemListener.fireOnUpdated(ItemListener.java:227)
	at jenkins.model.ParameterizedJobMixIn$ParameterizedJob.makeDisabled(ParameterizedJobMixIn.java:503)
	at org.jenkinsci.plugins.workflow.job.WorkflowJob.performDelete(WorkflowJob.java:640)
	at hudson.model.AbstractItem.delete(AbstractItem.java:675)
	at hudson.model.Job.delete(Job.java:681)
	at io.fabric8.jenkins.openshiftsync.BuildConfigWatcher$4.call(BuildConfigWatcher.java:466)
	at io.fabric8.jenkins.openshiftsync.BuildConfigWatcher$4.call(BuildConfigWatcher.java:462)
	at hudson.security.ACL.impersonate(ACL.java:260)
	at io.fabric8.jenkins.openshiftsync.BuildConfigWatcher.innerDeleteEventToJenkinsJob(BuildConfigWatcher.java:461)
	at io.fabric8.jenkins.openshiftsync.BuildConfigWatcher.deleteEventToJenkinsJob(BuildConfigWatcher.java:502)
	at io.fabric8.jenkins.openshiftsync.BuildConfigWatcher.eventReceived(BuildConfigWatcher.java:166)


Not sure if it has always been this way, or if we've ran into a new Jenkins "feature".

In any event, it appears we end up with both update and delete going and voila.  

The update winning appears to be consistent so far, so I'm thinking validating the fix (better synchronization between the update and delete paths, clearing out the cache immediately during delete so update processing aborts) should be straight forward.

And yes, part of that protection might/could/should also involve checking the annotations on whether the creation flow was bc->job or job-> bc.

https://github.com/openshift/jenkins-sync-plugin/pull/211 is in progress for delivering the fix.

Reminder, this list of steps is needed in order for QA to verify:
1) the above PR merges
2) we cut a new version of the plugin at the jenkins update center, in this case, it will be v1.0.7
3) we update the openshift jenkins repo to pull in that version of the plugin
4) we run the internal ci job to build the jenkins plugin rpm for our rhel image
5) an openshift jenkins rhel image with that rpm gets created in the brew-pulp machinery

I'll move this to ON_QA after I do 4), where QA can monitor brew-pulp for the image to verify.

v1.0.7 of openshift-sync plugin is available

https://github.com/openshift/jenkins/pull/512 brings it into the jenkins centos image

The job which updated the plugin rpm for the openshift jenkins rhel image is https://buildvm.openshift.eng.bos.redhat.com:8443/job/devex/job/devex%252Fjenkins-plugins/33/ and has completed and the dist-git http://pkgs.devel.redhat.com/cgit/rpms/jenkins-2-plugins/?h=rhaos-3.9-rhel-7 is updated.

Moving to on qa.  They should be able to track whether brew-pulp or the opsregistry generates an image with this rpm.

Thanks for the quick fix, Gabe! 
QE have tested with v1.0.7 plugin and pipeline buildconfig can be deleted and no recreate now. However, its related pods still exist. User can still access Jenkins console.

[wzheng@openshift-qe test]$ oc delete bc --all
buildconfig "nodejs-mongodb-example" deleted
buildconfig "sample-pipeline" deleted
[wzheng@openshift-qe test]$ oc get bc
No resources found.
[wzheng@openshift-qe test]$ oc get pods
NAME              READY     STATUS    RESTARTS   AGE
jenkins-1-kzzn7   1/1       Running   0          12m
mongodb-1-c82bc   1/1       Running   0          12m

Hi Wenjing,

The pods here will *NOT* be deleted just because you deleted the pipeline BC.
That is expected behavior.

Per comment #11, will verify this bug now.Thanks, Gabe!