CatalogSource pods not managed via Kubernetes controller

[pamelachristie]

Bug Report

The CatalogSource pod blocks kubectl drain commands as it is not managed by a Kubernetes controller.

What did you do?
Ran kubectl drain <NODE> on a cluster with a CatalogSource pod present.

What did you expect to see?
The kubectl drain should have proceeded without the pod causing a failure

What did you see instead? Under which circumstances?

cannot delete Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to override): ibm-system/addon-catalog-source-f2wnd

This result is due to the pod being not being managed by a Kubernetes controller.

Environment

• operator-lifecycle-manager version:
  0.14.1

• Kubernetes version information:
  1.16

• Kubernetes cluster kind:
  IBM Cloud

Possible Solution
Create a deployment or some other kind of Kubernetes controller to manage the pod rather than just the CatalogSource custom resource.

Additional context

[kramvan1]

Related to #1421

[kfox1111]

We've run into this too.

[kramvan1]

@ecordell I think this needs a higher priority as it's a valid scenario for both upstream and RH.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kramvan1]

This is still valid bug

[mhaideibm]

@kramvan1 we run into the same problem. As we need to replace Ubuntu 18 nodes with Ubuntu 16. Is there any outlook for this problem as this blocks us from going forward. Don't won't to drop that node when it is not backed up by ReplicaSet!

[kramvan1]

@mhaideibm I think we need to get this on the roadmap for OLM. https://docs.google.com/document/d/1Zuv-BoNFSwj10_zXPfaS9LWUQUCak2c8l48d0-AhpBw/edit#heading=h.8ngolbigvi7q

[pamelachristie]

Bump

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pamelachristie]

Bump

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contribution.
For more help on your issue, check out the olm-dev channel on the kubernetes slack [1] and the OLM Dev Working Group [2] [1] https://kubernetes.slack.com/archives/C0181L6JYQ2 [2] https://github.com/operator-framework/community#operator-lifecycle-manager-wg

[ecordell]

There is a tracking kube bug here: kubernetes/kubernetes#57049

Does drain with --force not solve the problem until this is addressed upstream?

[William-Newshutz]

A drain with --force is not a viable solution in this case. The pod had to be deleted with --force (which does not truly delete) before the drain could continue. This meant manual intervention because it blocked drain.

[philomory]

I noticed the PR for this was closed, is there any outlook on a replacement PR to actually get this addressed?