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

Invitation API and Storage #98

Merged
merged 7 commits into from
Feb 14, 2023
Merged

Invitation API and Storage #98

merged 7 commits into from
Feb 14, 2023

Conversation

bastjan
Copy link
Contributor

@bastjan bastjan commented Feb 6, 2023

Summary

Adds an Invitation object and stores it in a generic secretstorage.
The status handling of the resource is modeled after the official interfaces, but has prefixed methods to not trigger a storage registration bug.

Adds a reconciler for the newly created Invitation object that adds a token to the invitation.

apiserver/secretstorage/storage.go is the most important to review.

Checklist

  • PR contains a single logical change (to build a better changelog).
    Still way to big. Sorry 🤷‍♀️
  • Categorize the PR by setting a good title and adding one of the labels:
    bug, enhancement, documentation, change, breaking, dependency
    as they show up in the changelog.

@bastjan bastjan force-pushed the invitation-api branch 2 times, most recently from 43eab87 to aeb8c40 Compare February 10, 2023 15:10
@tobru tobru changed the title Inviation API and Storage Invitation API and Storage Feb 10, 2023
@bastjan bastjan self-assigned this Feb 13, 2023
@bastjan bastjan added the enhancement New feature or request label Feb 13, 2023
@bastjan bastjan requested a review from glrf February 13, 2023 10:36
@bastjan bastjan marked this pull request as ready for review February 13, 2023 10:37
Copy link
Contributor

@glrf glrf left a comment

Choose a reason for hiding this comment

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

LGTM, just a few nitpicks and don't forget RBAC I think the apiserver doesn't yet have access to secrets.

controllers/user_controller_test.go Outdated Show resolved Hide resolved

require.NoError(t, c.Get(ctx, types.NamespacedName{Name: subject.Name}, &subject))
assert.NotEmpty(t, subject.Status.Token)
assert.WithinDuration(t, time.Now().Add(tokenValidFor), subject.Status.ValidUntil.Time, time.Second)
Copy link
Contributor

Choose a reason for hiding this comment

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

Ntipick: This is technically a race condition. I really hope that this test will complete in a second, but technically it'd be better if we faked time.Now(). However that's a bit of a PITA, so feel free to ignore this comment

apiserver/secretstorage/status/status.go Show resolved Hide resolved
apiserver/secretstorage/storage.go Show resolved Hide resolved
Copy link
Member

@simu simu left a comment

Choose a reason for hiding this comment

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

LGTM

}

// TargetRef is a reference to a target resource
type TargetRef struct {
Copy link
Member

Choose a reason for hiding this comment

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

There's probably a good reason why we define TargetRef ourselves, but I'm wondering if we could just use the standard ObjectReference type instead.

Copy link
Contributor Author

@bastjan bastjan Feb 14, 2023

Choose a reason for hiding this comment

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

I think the reason was looking into the RoleBinding subjects instead of other references. Those don't have the right documentation when generated.

Using ObjectReference seems like a good idea but will introduce more validation overhead since there are more fields to respect and we'll most likely never use any of them.

Copy link
Member

Choose a reason for hiding this comment

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

I'm fine with having our own ref type especially since that will give us flexibility if we figure out that we need something that we can't get from ObjectReference. Additionally, there seems to be no clear consensus even in the core K8s types on whether you're supposed to use LocalObjectReference/ObjectReference vs your own ref types

Copy link
Contributor

@HappyTetrahedron HappyTetrahedron left a comment

Choose a reason for hiding this comment

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

I lack a lot of the context on this change so I can't say much about the overall approach. I didn't find any obvious issues in the code though, fwiw

controllers/invitation_token_controller.go Outdated Show resolved Hide resolved
@bastjan
Copy link
Contributor Author

bastjan commented Feb 14, 2023

don't forget RBAC

i did as always 😅

@bastjan bastjan merged commit b8c2aca into master Feb 14, 2023
@bastjan bastjan deleted the invitation-api branch February 14, 2023 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants