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

Modify DeactivationService to set scheduled deactivation time for active UserSignups #988

Merged
merged 57 commits into from
May 15, 2024

Conversation

sbryzak
Copy link
Contributor

@sbryzak sbryzak commented Mar 11, 2024

This PR updates the deactivation controller so that it will manage the UserSignup.Status.ScheduledDeactivationTimestamp property, setting it appropriately as the controller is reconciled, also when the user tier changes, and when the usersignup is deactivated.

Related PR: codeready-toolchain/registration-service#411

Copy link
Contributor

@alexeykazakov alexeykazakov left a comment

Choose a reason for hiding this comment

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

Looks good but I don't see any tests :)
And are you sure you want to combine the CRD/API update with the controller change? Usually we do it in separate PRs.

@sbryzak sbryzak changed the title Allow registration service to get/list/watch UserTier resources Modify DeactivationService to set scheduled deactivation time for active UserSignups Mar 16, 2024
@sbryzak
Copy link
Contributor Author

sbryzak commented Mar 26, 2024

/retest

Copy link
Contributor

@alexeykazakov alexeykazakov left a comment

Choose a reason for hiding this comment

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

Looks good overall. I have a few suggestions though.

controllers/deactivation/deactivation_controller.go Outdated Show resolved Hide resolved
controllers/deactivation/predicate.go Outdated Show resolved Hide resolved
controllers/deactivation/predicate.go Outdated Show resolved Hide resolved
controllers/deactivation/predicate.go Outdated Show resolved Hide resolved
@openshift-ci openshift-ci bot removed the approved label May 9, 2024
Copy link
Contributor

@alexeykazakov alexeykazakov left a comment

Choose a reason for hiding this comment

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

Looks good to me. We just need to add the status check in our e2e tests. We don't need to cover all the use cases but let's add the timestamp status check into at least some existing tests.

@@ -48,6 +50,7 @@ type Reconciler struct {
// Note:
// The Controller will requeue the Request to be processed again if the returned error is non-nil or
// Result.Requeue is true, otherwise upon completion it will remove the work from the queue.
// nolint: gocyclo
Copy link
Contributor

Choose a reason for hiding this comment

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

why?

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 linter believes that the reconcile function is too complex, so we disabled that check

Copy link
Contributor

Choose a reason for hiding this comment

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

Have you tried to re-enable it now? The code is less complex now then the initial one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, the linter still doesn't like it.

Copy link
Contributor

@MatousJobanek MatousJobanek May 17, 2024

Choose a reason for hiding this comment

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

have you considered refactoring the code and splitting the method into multiple ones? TBH, the linter is correct that the method is really complex and should be simplified/refactored.

@@ -128,6 +142,12 @@ func (r *Reconciler) Reconcile(ctx context.Context, request ctrl.Request) (ctrl.
if err := r.resetDeactivatingState(ctx, usersignup); err != nil {
return reconcile.Result{}, err
}
// Set the scheduled deactivation time to nil
if err := statusUpdater.SetScheduledDeactivationStatus(ctx, usersignup, nil); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the expected UX for:

  1. user won't be deactivated (is either excluded or is assigned to non-deactivating tier)
  2. the value cannot be not calculated for the account for some reasons

Do you want to show the same message/value for these two cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess since we can't actually differentiate between these two cases currently then a generic message or indicator would be most appropriate, perhaps for the "days remaining" box/field in the dashboard it can just display a - symbol or something.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah. Or N/A. Which can mean both Not Available and Not Applicable :)

controllers/usersignup/status_updater.go Outdated Show resolved Hide resolved
@sbryzak
Copy link
Contributor Author

sbryzak commented May 14, 2024

/retest

Copy link

openshift-ci bot commented May 14, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeykazakov, sbryzak

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:
  • OWNERS [alexeykazakov,sbryzak]

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

Copy link

sonarcloud bot commented May 15, 2024

Quality Gate Passed Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
13.9% Duplication on New Code

See analysis details on SonarCloud

Copy link

codecov bot commented May 15, 2024

Codecov Report

Attention: Patch coverage is 79.41176% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 84.72%. Comparing base (f426532) to head (1cbcfa9).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #988      +/-   ##
==========================================
+ Coverage   84.68%   84.72%   +0.03%     
==========================================
  Files          55       55              
  Lines        4877     4909      +32     
==========================================
+ Hits         4130     4159      +29     
- Misses        574      577       +3     
  Partials      173      173              
Files Coverage Δ
...ontrollers/deactivation/deactivation_controller.go 73.55% <100.00%> (+10.66%) ⬆️
controllers/deactivation/predicate.go 0.00% <ø> (ø)
controllers/usersignup/usersignup_controller.go 75.44% <0.00%> (-0.34%) ⬇️
controllers/usersignup/status_updater.go 91.96% <16.66%> (-1.37%) ⬇️

@sbryzak sbryzak merged commit e4b2e9c into codeready-toolchain:master May 15, 2024
10 of 12 checks passed
@sbryzak
Copy link
Contributor Author

sbryzak commented May 15, 2024

Merging now as I am on PTO from tomorrow. Codecov is lying about many of the lines not being covered, I added additional tests and confirmed with the debugger that it is indeed hitting those lines it's reporting as uncovered in the tests.

@sbryzak
Copy link
Contributor Author

sbryzak commented May 15, 2024

Just to add - if there is something else that anyone thinks needs to be addressed with this feature please mention it on our slack channel and we can address in a followup PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants