search

operator-framework / operator-lifecycle-manager

A management framework for extending Kubernetes with Operators
https://olm.operatorframework.io
Apache License 2.0
1.72k stars 545 forks source link

CatalogSource pods not managed via Kubernetes controller #1514

Open pamelachristie opened 4 years ago

pamelachristie commented 4 years ago

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

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 commented 4 years ago

Related to #1421

kfox1111 commented 4 years ago

We've run into this too.

kramvan1 commented 4 years ago

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

stale[bot] commented 4 years ago

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 commented 4 years ago

This is still valid bug

mhaideibm commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

Bump

stale[bot] commented 3 years ago

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 commented 3 years ago

Bump

stale[bot] commented 3 years ago

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 commented 3 years ago

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?

William-Newshutz commented 3 years ago

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 commented 1 year ago

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