Skip to content

add request-received-time annotation #515

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

Conversation

MatousJobanek
Copy link
Contributor

Adds request-received-time annotation to store when the request to either signup or reactivate the account was received.
This will be used by the host-operator to record the provision time in a histogram.

We cannot measure the time in registration-service, because it would create a hard dependency on the calls made by the client. Reg-service could measure it only when the user keeps the browser open so the UI keeps sending requests to reg-service. However, if the user closes (or leaves) the UI, reg-service won't be triggered to record the provision time.

depends on codeready-toolchain/api#464
SANDBOX-957

userSignup := &toolchainv1alpha1.UserSignup{
ObjectMeta: metav1.ObjectMeta{
Name: signupcommon.EncodeUserIdentifier(ctx.GetString(context.UsernameKey)),
Namespace: configuration.Namespace(),
Annotations: map[string]string{
toolchainv1alpha1.UserSignupVerificationCounterAnnotationKey: "0",
toolchainv1alpha1.UserSignupRequestReceivedTimeAnnotationKey: requestReceivedTime.(time.Time).Format(time.RFC3339),
Copy link
Contributor

Choose a reason for hiding this comment

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

if I understand correctly, we're not tracking the milliseconds, so is there a risk of significant loss of precision in the measures?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we can measure milliseconds or even nanoseconds, but does it really matter? can you notice that you need to wait 500millisecond more or less?

Copy link
Contributor Author

@MatousJobanek MatousJobanek Feb 25, 2025

Choose a reason for hiding this comment

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

one more thing, the buckets in the histogram are distributed by seconds anyway, so measuring milliseconds doesn't bring any benefit in distributing the numbers in the buckets.
https://github.com/codeready-toolchain/host-operator/pull/1148/files#diff-4bc91a74bc47b8467cdcd25a7e3fe1651dbe44907f478377eca31b982f444f23R145

As I see it, we should care about provision time that takes more than 10 seconds, milliseconds at this scale doesn't play any role. That's why I decided to keep it simple and use the standard RFC3339 format.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, let's see how the histogram buckets will be filled, then
Also, buckets can be configured

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, buckets can be configured

this is exactly what I do in the host-operator PR, see the link that I pasted in my previous comment.

Copy link

codecov bot commented Feb 25, 2025

Codecov Report

Attention: Patch coverage is 70.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 85.24%. Comparing base (60b898f) to head (c32f917).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
pkg/server/routes.go 40.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #515      +/-   ##
==========================================
- Coverage   85.30%   85.24%   -0.06%     
==========================================
  Files          32       32              
  Lines        3109     3117       +8     
==========================================
+ Hits         2652     2657       +5     
- Misses        371      373       +2     
- Partials       86       87       +1     
Flag Coverage Δ
unittests 85.24% <70.00%> (-0.06%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -78,6 +79,8 @@ func (s *TestSignupServiceSuite) TestSignup() {
require.True(s.T(), states.VerificationRequired(&val))
require.Equal(s.T(), "a7b1b413c1cbddbcd19a51222ef8e20a", val.Labels[toolchainv1alpha1.UserSignupUserEmailHashLabelKey])
require.Empty(s.T(), val.Annotations[toolchainv1alpha1.SkipAutoCreateSpaceAnnotationKey]) // skip auto create space annotation is not set by default
require.NotEmpty(s.T(), val.Annotations)
require.Equal(s.T(), requestTime.Format(time.RFC3339), val.Annotations[toolchainv1alpha1.UserSignupRequestReceivedTimeAnnotationKey])
Copy link
Contributor

Choose a reason for hiding this comment

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

That assumes that the test is finished within 1s. Which should be the case in a normal test run. But at least maybe worth adding a comment? Just in case, for whatever reason, the test fails due to some delay (during test debugging for example), so it could help to understand why it failed.

Copy link
Contributor

Choose a reason for hiding this comment

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

or should we just assert that the annotation is there and has a valid time.RFC3339 formatted value ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not really, this test doesn't rely on the execution time anyhow - the requestTime is set once at the beginning of the suite

and the same value is set in the context

ctx.Set(context.RequestReceivedTime, requestTime)

and the same value is also used for comparison

require.Equal(s.T(), requestTime.Format(time.RFC3339), val.Annotations[toolchainv1alpha1.UserSignupRequestReceivedTimeAnnotationKey])

So, it doesn't matter how long the test runs, it will always pass. (I've tested it locally)

Copy link

Copy link

openshift-ci bot commented Feb 27, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeykazakov, MatousJobanek, xcoulon

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 [MatousJobanek,alexeykazakov,xcoulon]

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

@MatousJobanek MatousJobanek merged commit d4f3575 into codeready-toolchain:master Feb 27, 2025
11 of 13 checks passed
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.

4 participants