feat(enterprise/coderd): allow system users to be added to groups #18341
Conversation
…tem user so that they can configure quotas
There was a problem hiding this comment.
I'm wondering about this approach. Do we need to add IncludeSystem: true to all these queries just to support the prebuilds system user?
This means someone will need to manually create a group for the prebuilds user and assign it a quota, right?
Wouldn't it be more robust to automatically create a group for the prebuilds system user with a default quota, and allow users to override it if needed? That way, we avoid having to include system users in these queries and reduce the risk of system users leaking into user-facing features.
|
The prebuilds user has already leaked into user facing features. Administrators search for prebuilds by specifying the prebuilds user on the workspace list page. For consistency and clarity, I think we should embrace listing and showing the prebuilds user. I like the idea of automatically creating a prebuilds group, but we'll need to decide what a sensible default quota would be if there is such a value that makes sense. |
It’s true that the prebuilds user is already exposed in some user-facing features, like showing prebuilt workspaces, but that might not be the ideal approach 😕 The issue isn’t just about the prebuilds user, it extends to listing all current and future system users.
We already have a precedent with the coder/coderd/database/queries/groups.sql Lines 102 to 109 in 0cdcf89 We could apply the same pattern here: automatically create the prebuilds group with a default quota of 0, and clearly document this behavior along with instructions on how users can update the quota if needed. |
WalkthroughThis change updates the logic for retrieving organization and group members to consistently include system users, such as the prebuilds system user, by default. It introduces a new boolean parameter to control this behavior in both SQL queries and Go code, and updates related tests to expect the presence of system users in member lists. Changes
Sequence Diagram(s)sequenceDiagram
participant API
participant MembersService
participant Database
API->>MembersService: Request organization/group members
MembersService->>Database: Query members (IncludeSystem: true)
Database-->>MembersService: Return all members (including system users)
MembersService-->>API: Return member list with system users
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Could we also add a test case that verifies the behavior when the prebuilds quota is actually used? I'm curious about what QuotaAllowance: 0 means in practice, does this mean prebuild creation will always fail due to no quota, or does 0 represent unlimited/no enforcement?
It would be helpful to have a test that actually attempts to create prebuilds after the group is set up to clarify this behavior and ensure the default quota setting works as intended.
|
@ssncferreira I've added unit tests to verify the scope of quotas. You were right. Quotas are org scoped. Prebuilds might reach it's quota in one organization while still having some budget left in another. The added tests prove the desired behaviour for all users, including prebuilds. I'm planning a follow up where the prebuilds user checks its quota before it attempts to create a new workspace and fails early if it would exceed the quota. |
| // ZeroQuota tests that a user with a zero quota allowance can't create a workspace. | ||
| // Although relevant for all users, this test ensures that the prebuilds system user | ||
| // cannot create workspaces in an organization for which it has exhausted its quota. | ||
| t.Run("ZeroQuota", func(t *testing.T) { |
There was a problem hiding this comment.
While it's good to have this test, it would be best to explicitly test this scenario with the prebuilds reconciler.
| require.Equal(t, "Everyone", group.Name) | ||
| require.Equal(t, user.OrganizationID, group.OrganizationID) | ||
| require.Contains(t, group.Members, user1.ReducedUser) | ||
| require.Contains(t, group.Members, user2.ReducedUser) | ||
| require.NotContains(t, group.Members, prebuildsUser.ReducedUser) | ||
| require.Contains(t, group.Members, prebuildsUser.ReducedUser) |
There was a problem hiding this comment.
Should we include system users in the Everyone group? IIUC with this change, prebuilds users will inherit the quota from this group, is that something that we want? Shouldn't it be limited to the prebuilds group? As previously discussed, I'm not entirely convinced we should treat system users as normal users in these workflows 👀 but if there is a general consensus, I'm ok with it
There was a problem hiding this comment.
I do think we should include the prebuilds user in the Everyone group at least until we have a second "system user".
There was a problem hiding this comment.
@mtojek Would you be able to provide consensus or this?
|
Internal consensus: |
closes #18274
This pull request makes system users visible in various group related queries so that they can be added to and removed from groups. This allows system user quotas to be configured. System users are still ignored in certain queries, such as when license seat consumption is determined.
This pull request further ensures the existence of a "coder_prebuilt_workspaces" group in any organization that needs prebuilt workspaces
Summary by CodeRabbit