Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set degraded if nmstate is requested in networkAddonsConfig #1292

Conversation

rhrazdil
Copy link
Contributor

@rhrazdil rhrazdil commented Mar 22, 2022

What this PR does / why we need it:
This PR aims to block upgrade if still using CNAO to deploy nmstate by Setting NetworkAddonsConfig Degraded Status to true.
HCO will reconcile it and see that the NAC status is degraded, consequently it will set it's status upgradeable to false.

See HCO: https://github.com/kubevirt/hyperconverged-cluster-operator/blob/main/controllers/hyperconverged/hyperconverged_controller.go#L740

That will block upgrade until user installs KNO (Kubernetes Nmstate Operator).

Special notes for your reviewer:

HCO change:

Release note:

Block CNV upgrade if still using CNAO to deploy nmstate

@kubevirt-bot kubevirt-bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Mar 22, 2022
@rhrazdil rhrazdil force-pushed the block_411_upgrade_if_nmstate_deployed_without_kno branch 2 times, most recently from ce457b8 to cd824e9 Compare March 23, 2022 07:07
@rhrazdil
Copy link
Contributor Author

/hold

@kubevirt-bot kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 23, 2022
@rhrazdil rhrazdil changed the title WIP Set degraded if nmstate is deployed on OCP 4.11 or later Set degraded if nmstate is deployed on OCP 4.11 or later Mar 23, 2022
@kubevirt-bot kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 23, 2022
@rhrazdil
Copy link
Contributor Author

/hold cancel

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 29, 2022
@rhrazdil rhrazdil force-pushed the block_411_upgrade_if_nmstate_deployed_without_kno branch 2 times, most recently from 289bc4c to 2752eed Compare March 30, 2022 06:50
@rhrazdil
Copy link
Contributor Author

Hello @tiraboschi @qinqon @RamLavi
Could you please review this PR?

Copy link
Collaborator

@qinqon qinqon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need to check openshift.

reason := "InvalidConfiguration"
message := "NMState deployment is not provided in CNV >= 4.11, please install Kubernetes NMState Operator"
status.eventEmitter.EmitFailingForConfig(reason, message)
conditionsv1.SetStatusConditionNoHeartbeat(&config.Status.Conditions,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should change heartbeat right ? it's not a noop

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right correct

},
)
config.Status.ObservedVersion = operatorVersion
if status.isRunningOnOpenshift411OrLater() && config.Spec.NMState != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we don't need to check openshift at all at the end at this u/s release for wherever is running we will fail on invalid networkaddonsconfig meaning that if they ask for NMState we fail, openshift kubernetes or whatever.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is, if we don't check OCP 4.11, then we block not only upgrade from CNV 4.10 to 4.11, but also all z-stream upgrades on 4.10

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, we could notify u/s users as you suggest

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not backporting this so this code will run only on OCP > 4.10

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, we have to backport this to 4.10. If we didn't backport this a have this code in 4.11, then by the time users upgrade OCP to 4.11 and CNV to 4.11, it's already too late.

} else {
// If successfully deployed all components and is not failing on anything, mark as Available
status.eventEmitter.EmitAvailableForConfig()
conditionsv1.SetStatusConditionNoHeartbeat(&config.Status.Conditions,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should change heratbeat if previous condition was not success, although I don't know if we can check that or if it's worth it.

Copy link
Collaborator

@RamLavi RamLavi Mar 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo if we don't keep track about the heartbeat anymore then there's no need to update it in any scenario - neither good or bad.
We do have the TransitionTimestamp (when the status last changed value) which might be enough, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so we don't want to update it in #1292 (comment) either, correct?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then feels like heartbeat is kind of obsolete and replaced by TransitionTimestamp ?

Copy link
Collaborator

@RamLavi RamLavi Apr 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[fixing the name of TransitionTimestamp - exact name is LastTransitionTime)

So, it doesn't replace LastTransitionTime because LastTransitionTime is already on the original SetStatusCondition() function.

heartbeat is no longer published on CNAO. This is because it also causes a resourceVersion change (every 1 minute) and that triggers a repeating reconcile on HCO.
As a result, we decided to move to SetStatusConditionNoHeartbeat on main and release-0.65 branches.

HCO will reconcile and see that the NAC status is degraded
and in turn set it's status upgradeable to false.

That will block upgrade until user installs KNO

Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
@rhrazdil rhrazdil force-pushed the block_411_upgrade_if_nmstate_deployed_without_kno branch from 2752eed to e436a2a Compare April 1, 2022 09:21
@sonarcloud
Copy link

sonarcloud bot commented Apr 1, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@rhrazdil rhrazdil changed the title Set degraded if nmstate is deployed on OCP 4.11 or later Set degraded if nmstate is requested in networkAddonsConfig Apr 1, 2022
@rhrazdil
Copy link
Contributor Author

rhrazdil commented Apr 1, 2022

After discussing with @qinqon I'm setting the Degraded condition always when nmstate is requested.
In a backport to release-0.65, I only do so if we find we're running on OCP 4.11
#1323

@qinqon
Copy link
Collaborator

qinqon commented Apr 4, 2022

/lgtm
/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Apr 4, 2022
@kubevirt-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qinqon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 4, 2022
@kubevirt-bot kubevirt-bot merged commit 575bdd5 into kubevirt:main Apr 4, 2022
rhrazdil pushed a commit to rhrazdil/cluster-network-addons-operator that referenced this pull request May 24, 2022
rhrazdil pushed a commit to rhrazdil/cluster-network-addons-operator that referenced this pull request May 24, 2022
…evirt#1292)"

This reverts commit 575bdd5.

Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
kubevirt-bot pushed a commit that referenced this pull request May 24, 2022
…)" (#1361)

This reverts commit 575bdd5.

Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants