Bug 2029359

Summary: NodeNetworkConfigurationPolicy refreshes all the conditions even if the policy has not gone to that state
Product: Container Native Virtualization (CNV) Reporter: Geetika Kapoor <gkapoor>
Component: NetworkingAssignee: Radim Hrazdil <rhrazdil>
Status: CLOSED ERRATA QA Contact: awax
Severity: unspecified Docs Contact:
Priority: medium    
Version: 4.9.0CC: cnv-qe-bugs, phoracek, rhrazdil
Target Milestone: ---   
Target Release: 4.10.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kubernetes-nmstate-handler v4.10.1-11 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-18 20:26:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Geetika Kapoor 2021-12-06 10:05:27 UTC
Description of problem:

NodeNetworkConfigurationPolicy refreshes all the conditions even if the policy has not gone to that state. For example: when we set maxunavailable as 100%, we expect that all nodes will goto 
'type': 'Progressing' and from there just two states are possible.
Either available or Failing but it changes the timestamp(heartbeat, transition time, reason, status for all the other states that are never used for involved in this process which is showing wrong data to users.

There is another theory to it, If we are not doing transition to one particular state, why we actually need them to show here.

Also, timestamps are not right as we never transition to that state.
Example:


  Conditions:
    Last Hearbeat Time:    2021-12-02T06:43:42Z
    Last Transition Time:  2021-12-02T06:43:42Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Progressing
    Last Hearbeat Time:    2021-12-02T06:43:42Z
    Last Transition Time:  2021-12-02T06:43:42Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Failing
    Last Hearbeat Time:    2021-12-02T06:43:42Z
    Last Transition Time:  2021-12-02T06:43:42Z
    Message:               successfully reconciled
    Reason:                SuccessfullyConfigured
    Status:                True
    Type:                  Available
    Last Hearbeat Time:    2021-12-02T06:43:42Z
    Last Transition Time:  2021-12-02T06:43:42Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Pending
    Last Hearbeat Time:    2021-12-02T06:43:42Z
    Last Transition Time:  2021-12-02T06:43:42Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Aborted


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

How reproducible:
always 

Steps to Reproduce:
1. Start any nncp policy and run the describe to get status.
2.
3.

Actual results:
as mentioned above, all the above data provided is either not useful and also as a user i don't know what all states the policy got transitioned to.
For example the above one it can goto only 2 states but it changes timestamp, reason and states for all types even when they are never used states.

Expected results:

1. Expectations is user should be able to know what all state transition happen.
2. Show/update timestamp , reason based on that.
3. If possible show only meaning types(state).
Additional info:

Comment 1 Radim Hrazdil 2022-03-21 14:51:23 UTC
The bug description says NodeNetworkConfigurationPolicy, but the conditions listed are used in NodeNetworkConfigurationEnactments,
I take it as we're talking about NNCEs then.

>NodeNetworkConfigurationPolicy refreshes all the conditions even if the policy has not gone to that state. For example: when we set maxunavailable as 100%, we expect that all nodes will goto 
'type': 'Progressing' and from there just two states are possible.
Either available or Failing but it changes the timestamp(heartbeat, transition time, reason, status for all the other states that are never used for involved in this process which is showing wrong data to users.


I wouldn't say that other states are not used in the process. For example, we set a value False to condition Aborted. That is a valid, meaningful, and correct value. 
It simply states, that at certain moment, this condition is false.

What is indeed not correct is the Last Transition Time, as in this case, the LTT should hold the value that set to the condition initially.

Comment 2 Petr Horáček 2022-04-14 08:29:35 UTC
This is pending U/S nmstate release

Comment 3 awax 2022-05-04 12:04:21 UTC
verified on CNV v.4.10.1.
[cnv-qe-jenkins@n-awax-4101-ffpz9-executor anat]$ oc get csv -A -n openshift
NAMESPACE                              NAME                                         DISPLAY                       VERSION               REPLACES                                   PHASE
openshift-cnv                          kubevirt-hyperconverged-operator.v4.10.1     OpenShift Virtualization      4.10.1                kubevirt-hyperconverged-operator.v4.10.0   Succeeded

[cnv-qe-jenkins@n-awax-4101-ffpz9-executor anat]$ oc version
Client Version: 4.10.0-202204291519.p0.g09f825e.assembly.stream-09f825e
Server Version: 4.10.12
Kubernetes Version: v1.23.5+70fb84c

networkaddonsoperator.network.kubevirt.io/version=sha256_f94b654f5cb30f20b73f5bb39d621893886959991040c6ba217e7b88 (v4.10.1-12)




steps to verify:
1. I created an NNCP and waited for it to be configured successfully.
2. I looked at the 'Last Hearbeat Time' and the 'Last Transition Time' in the Conditions field and made sure that in conditions that were not met (Pending and Aborted), the Hearbeat and Transition timestamp were different:
Status:
  Conditions:
    Last Hearbeat Time:    2022-05-04T10:29:15Z
    Last Transition Time:  2022-05-04T10:29:15Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Progressing
    Last Hearbeat Time:    2022-05-04T10:29:15Z
    Last Transition Time:  2022-05-04T10:29:15Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Failing
    Last Hearbeat Time:    2022-05-04T10:29:15Z
    Last Transition Time:  2022-05-04T10:29:15Z
    Message:               successfully reconciled
    Reason:                SuccessfullyConfigured
    Status:                True
    Type:                  Available
    Last Hearbeat Time:    2022-05-04T10:29:15Z
    Last Transition Time:  2022-05-04T10:29:04Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Pending
    Last Hearbeat Time:    2022-05-04T10:29:15Z
    Last Transition Time:  2022-05-04T10:29:04Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Aborted

3. I also verified by changing the policy and waiting for it to be configured successfully:
Status:
  Conditions:
    Last Hearbeat Time:    2022-05-04T10:37:48Z
    Last Transition Time:  2022-05-04T10:37:48Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Progressing
    Last Hearbeat Time:    2022-05-04T10:37:48Z
    Last Transition Time:  2022-05-04T10:37:48Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Failing
    Last Hearbeat Time:    2022-05-04T10:37:48Z
    Last Transition Time:  2022-05-04T10:37:48Z
    Message:               successfully reconciled
    Reason:                SuccessfullyConfigured
    Status:                True
    Type:                  Available
    Last Hearbeat Time:    2022-05-04T10:37:48Z
    Last Transition Time:  2022-05-04T10:37:37Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Pending
    Last Hearbeat Time:    2022-05-04T10:37:48Z
    Last Transition Time:  2022-05-04T10:37:37Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Aborted

4. I also verified by editing the policy so that the nnce would fail (Failing status):
Status:
  Conditions:
    Last Hearbeat Time:    2022-05-04T10:55:08Z
    Last Transition Time:  2022-05-04T10:55:08Z
    Reason:                FailedToConfigure
    Status:                False
    Type:                  Progressing
    Last Hearbeat Time:    2022-05-04T10:55:08Z
    Last Transition Time:  2022-05-04T10:55:08Z
    Message:               error reconciling NodeNetworkConfigurationPolicy at desired state apply: ,
failed to execute nmstatectl set --no-commit --timeout 480: 'exit status 1'
...
...
ZPCnJ2q19OpQrK3Zxej/AgAA///5XGgs8WcBAA==
    Reason:                FailedToConfigure
    Status:                True
    Type:                  Failing
    Last Hearbeat Time:    2022-05-04T10:55:08Z
    Last Transition Time:  2022-05-04T10:55:08Z
    Reason:                FailedToConfigure
    Status:                False
    Type:                  Available
    Last Hearbeat Time:    2022-05-04T10:55:08Z
    Last Transition Time:  2022-05-04T10:54:58Z
    Reason:                FailedToConfigure
    Status:                False
    Type:                  Pending
    Last Hearbeat Time:    2022-05-04T10:55:08Z
    Last Transition Time:  2022-05-04T10:54:58Z
    Reason:                SuccessfullyConfigured
    Status:                False
    Type:                  Aborted

Comment 9 errata-xmlrpc 2022-05-18 20:26:57 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 (Moderate: OpenShift Virtualization 4.10.1 Images security and bug fix update), 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/RHSA-2022:4668