Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1685911 - kubevirt project cannot be deleted and keep in Terminating status for a long time
Summary: kubevirt project cannot be deleted and keep in Terminating status for a long ...
Keywords:
Status: NEW
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 1.4
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: 2.1
Assignee: David Vossel
QA Contact: Israel Pinto
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-06 09:44 UTC by Yan Du
Modified: 2019-04-02 13:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Yan Du 2019-03-06 09:44:58 UTC
Description of problem:

$ oc get project kubevirt
NAME       DISPLAY NAME   STATUS
kubevirt                  Terminating

Version-Release number of selected component (if applicable):
openshift v3.11.69
kubernetes v1.11.0+d4cacc0
CNV 1.4

How reproducible:
not sure

Steps to Reproduce:
1. Setup up a cluster openshift+cnv
2. Make sure all the kubevirt components are deployed in the cluster
3. Delete the kubevirt project
# oc delete project kubevirt
4. Check the project
5. Check the log on master controller

Actual results:
4. kubevirt project keeps in Terminating status for a long time
5. Got some log from the master:

E0227 02:25:11.137161       1 namespace_controller.go:148] unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server could not find the requested resource, subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request, upload.cdi.kubevirt.io/v1alpha1: the server could not find the requested resource
E0227 02:25:11.788511       1 namespace_controller.go:148] unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server could not find the requested resource, subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request, upload.cdi.kubevirt.io/v1alpha1: the server could not find the requested resource
E0227 02:25:13.094867       1 namespace_controller.go:148] unable to retrieve the complete list of server APIs: subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request, upload.cdi.kubevirt.io/v1alpha1: the server could not find the requested resource
E0227 02:25:15.676392       1 namespace_controller.go:148] unable to retrieve the complete list of server APIs: subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request
E0227 02:25:20.812375       1 namespace_controller.go:148] unable to retrieve the complete list of server APIs: subresources.kubevirt.io/v1alpha3: the server is currently unable to handle the request


Expected results:
Kubevirt project can be deleted normally

Additional info:

I met same problem once when we were still using subresources.kubevirt.io/v1alpha2, the kubevirt project can not deleted and keep in Terminating, but after I delete the apiserivers (#oc delete apiservices v1alpha2.subresources.kubevirt.io). the kubevirt can be deleted normally.
But for the subresources.kubevirt.io/v1alpha3, the workaround doesn't work anymore.

Comment 1 Yan Du 2019-03-06 09:57:36 UTC
And a question about the apiversion, seems there are two api versions, is it by designed?
$ oc get apiservices v1alpha1.kubevirt.io 
NAME                   CREATED AT
v1alpha1.kubevirt.io   2019-03-06T03:06:17Z
$ oc get apiservices v1alpha3.kubevirt.io 
NAME                   CREATED AT
v1alpha3.kubevirt.io   2019-03-06T03:05:14Z

Comment 3 Fabian Deutsch 2019-03-07 08:57:36 UTC
David, any idea?

Comment 4 David Vossel 2019-03-08 22:27:37 UTC
Something is wrong with this environment if there are two versions of the kubevirt.io apiservice. For me, that indicates something hasn't been cleaned up properly from a previous kubevirt install.


I'm really not sure what's going on here. Why are we trying to delete the kubevirt namespace?  That's not really the proper way to deprovision KubeVirt.

Comment 5 Yan Du 2019-03-11 02:15:59 UTC
(In reply to David Vossel from comment #4)
> Something is wrong with this environment if there are two versions of the
> kubevirt.io apiservice. For me, that indicates something hasn't been cleaned
> up properly from a previous kubevirt install.
>
I have checked the upstream env (deploy by kubevirt-ansible on a fresh OCP env), there are still two apiversion there.
 
> 
> I'm really not sure what's going on here. Why are we trying to delete the
> kubevirt namespace?  That's not really the proper way to deprovision
> KubeVirt.
Yes, the best way to deprovison kubevirt is using the kubevirt-ansbile playbook. Maybe deleting the project is a abnormal operation, but what if the user does that? Seems there is no appropriate way to recover the env except re-installing a new one.


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