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

Sandbox 554 #404

Merged
merged 8 commits into from
Mar 15, 2024
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions api/v1alpha1/usersignup_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -247,6 +247,12 @@ type UserSignupStatus struct {
// This is used by the proxy when no workspace context is provided.
// +optional
HomeSpace string `json:"homeSpace,omitempty"`

// DeactivationTimestamp is the calculated timestamp after which the user's account will be deactivated, typically
// after the expiry of their trial and based on the term specific by their UserTier. This property may be used as
// a convenience to determine the amount of time an account has left before deactivation, without requiring a separate
// lookup for the UserTier and subsequent calculation. It is managed by the Deactivation controller in the host operator.
DeactivationTimestamp string `json:"deactivationTimestamp,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't it be stored in one of the status.conditions, instead? We already add a status condition when a user is activated or banned, so why using something different for deactivations?

Copy link
Contributor

Choose a reason for hiding this comment

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

ah never mind, this is the expected time of deactivation, not the actual one (ie, after the user was deactivated).

Copy link
Contributor

Choose a reason for hiding this comment

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

so this field will need to be updated when a user is moved to another tier.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's maybe rename it to ExpectedTimeOfDeactivation or something like that to make it clear.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, could you please explain why you decided to use string? what is the expected format/content?
Why don't you use metav1.Time as we use in conditions?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @MatousJobanek. Something like ExpectedTimeOfDeactivation with metav1.Time type would look better.

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've renamed it to ScheduledDeactivationTimestamp, and also modified the type to use metav1.Time instead of a string to bring it inline with the rest of the API (before I saw these comments, so at least we were all on the same page ;).

sbryzak marked this conversation as resolved.
Show resolved Hide resolved
}

//+kubebuilder:object:root=true
Expand Down
7 changes: 7 additions & 0 deletions api/v1alpha1/zz_generated.openapi.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading