operator-lifecycle-manager icon indicating copy to clipboard operation
operator-lifecycle-manager copied to clipboard

CatalogSource pods not managed via Kubernetes controller

Open pamelachristie opened this issue 5 years ago • 14 comments

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

pamelachristie avatar May 12 '20 16:05 pamelachristie

Related to #1421

kramvan1 avatar Jun 08 '20 18:06 kramvan1

We've run into this too.

kfox1111 avatar Jun 18 '20 18:06 kfox1111

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

kramvan1 avatar Jun 19 '20 15:06 kramvan1

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.

stale[bot] avatar Aug 18 '20 18:08 stale[bot]

This is still valid bug

kramvan1 avatar Aug 18 '20 18:08 kramvan1

@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!

mhaideibm avatar Sep 01 '20 13:09 mhaideibm

@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

kramvan1 avatar Sep 21 '20 18:09 kramvan1

Bump

pamelachristie avatar Oct 12 '20 15:10 pamelachristie

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.

stale[bot] avatar Dec 11 '20 17:12 stale[bot]

Bump

pamelachristie avatar Dec 11 '20 17:12 pamelachristie

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

stale[bot] avatar Mar 12 '21 03:03 stale[bot]

There is a tracking kube bug here: https://github.com/kubernetes/kubernetes/issues/57049

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

ecordell avatar Mar 15 '21 14:03 ecordell

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.

William-Newshutz avatar Apr 19 '21 18:04 William-Newshutz

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

philomory avatar May 29 '23 20:05 philomory