Bug 1815145 - Can't re-deploy HCO. KubevirtNodeLabellerBundle resource has no conditions
Summary: Can't re-deploy HCO. KubevirtNodeLabellerBundle resource has no conditions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: SSP
Version: 2.3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.3.0
Assignee: Karel Šimon
QA Contact: Satyajit Bulage
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-19 15:34 UTC by Nahshon Unna-Tsameret
Modified: 2023-09-14 05:54 UTC (History)
8 users (show)

Fixed In Version: kubevirt-ssp-operator-container-v2.3.0-33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-04 19:10:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
SSP log (58.31 KB, application/gzip)
2020-03-19 15:34 UTC, Nahshon Unna-Tsameret
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:2011 0 None None None 2020-05-04 19:11:10 UTC

Description Nahshon Unna-Tsameret 2020-03-19 15:34:09 UTC
Created attachment 1671489 [details]
SSP log

Description of problem:
Can't re-deploy HCO, SSP does not report conditions


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Deploy KubeVirt + HCO
2. Delete the HCO operator and wait to all the other operators to be removed as well.
3. Create HCO again

Actual results:
HCO is Active and Upgradeble 

Expected results:
HCO condition is always Processing = True, Available = False


```
- lastHeartbeatTime: '2020-03-18T08:07:18Z'
  lastTransitionTime: '2020-03-18T08:05:28Z'
  message: KubevirtNodeLabellerBundle resource has no conditions
  reason: KubevirtNodeLabellerBundleConditions
  status: 'False'
  type: Available
- lastHeartbeatTime: '2020-03-18T08:07:18Z'
  lastTransitionTime: '2020-03-18T08:05:28Z'
  message: KubevirtNodeLabellerBundle resource has no conditions
  reason: KubevirtNodeLabellerBundleConditions
  status: 'True'
  type: Progressing
```

Additional info:
```
oc get KubevirtCommonTemplatesBundle -n openshift -o yaml
apiVersion: v1
items:
- apiVersion: ssp.kubevirt.io/v1
  kind: KubevirtCommonTemplatesBundle
  metadata:
    creationTimestamp: 2020-03-18T13:33:29Z
    generation: 1
    labels:
      app: kubevirt-hyperconverged
    name: common-templates-kubevirt-hyperconverged
    namespace: openshift
    resourceVersion: "604948"
    selfLink: /apis/ssp.kubevirt.io/v1/namespaces/openshift/kubevirtcommontemplatesbundles/common-templates-kubevirt-hyperconverged
    uid: 167ab782-95ad-424e-ac3b-3a31f5326b9a
  spec: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
```

Comment 1 Simone Tiraboschi 2020-03-19 16:53:07 UTC
I think that the reproduction steps are not that accurate,
the correct path is 

Steps to Reproduce:
1. Deploy CNV and create HCO CR, wait for it to be successfully running with ready=1
2. Delete the HCO CR and wait to all the other operators CRs to be removed as well
3. Create HCO CR again

Comment 3 Karel Šimon 2020-03-23 10:19:38 UTC
It looks like ssp is randomly ignoring recreated CRs. I updated ssp with latest ansible operator, we will see if it fixes it.

Comment 6 Nelly Credi 2020-03-24 09:55:07 UTC
Seems like this will block upgrade flow
targeting to 2.3 
we need PM ack

Comment 7 Karel Šimon 2020-03-27 11:38:40 UTC
I found all root causes of this bug (https://github.com/MarSik/kubevirt-ssp-operator/pull/158, https://github.com/MarSik/kubevirt-ssp-operator/pull/157). New containers are being built.

Comment 8 Satyajit Bulage 2020-04-01 12:52:18 UTC
Performed following steps:
1. Deploy CNV 2.3 with HCO CR (wait till all pods are running)
2. Deleted HCO and stopped for related pods to remove
3. Again added HCO CR in the cluster and wait for all pods are running

Here is output of HCO hearbeats:

    - lastHeartbeatTime: '2020-04-01T12:44:30Z'
      lastTransitionTime: '2020-04-01T11:57:50Z'
      message: Reconcile completed successfully
      reason: ReconcileCompleted
      status: 'True'
      type: Available
    - lastHeartbeatTime: '2020-04-01T12:44:30Z'
      lastTransitionTime: '2020-04-01T11:57:50Z'
      message: Reconcile completed successfully
      reason: ReconcileCompleted
      status: 'False'
      type: Progressing

Hence Verifying this Bugzilla.

Comment 11 errata-xmlrpc 2020-05-04 19:10:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:2011

Comment 12 Red Hat Bugzilla 2023-09-14 05:54:31 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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