-
Notifications
You must be signed in to change notification settings - Fork 55
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
Add support for per-namespace configuration and add setting for workspace PVC request size #487
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM
will test soon
) | ||
|
||
const ( | ||
commonPVCSizeKey = "commonPVCSize" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, during testing I found more config we may want to configure, but I'm not sure.
Like pvc name. For CRW it's claim-che-workspace, not sure if CRW expects Che Workspace and DevWorkspaces uses different PVCs.
Also, see che.infra.kubernetes.pvc.storage_class_name.
it's out of the current PR scope for sure, but WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea was that the config struct could be extended to include additional information as needed (storage class makes sense).
For common PVC name, I think it's a limited use case that would be complex to support -- e.g. what happens if it is updated after claim-che-workspace
has been created? It seems like it would be an open door for leaking storage after workspaces are deleted, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and it works fine
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amisevsk, sleshchenko 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:
Approvers can indicate their approval by writing |
/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path |
bc01b98
to
2e67975
Compare
New changes are detected. LGTM label has been removed. |
/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path |
Add support for configuring namespace-wide settings for DevWorkspaces by created a configmap with the appropriate label. Signed-off-by: Angel Misevski <amisevsk@redhat.com>
Signed-off-by: Angel Misevski <amisevsk@redhat.com>
Signed-off-by: Angel Misevski <amisevsk@redhat.com>
2e67975
to
43e2590
Compare
/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path |
/test v7-devworkspaces-operator-e2e |
What does this PR do?
controller.devfile.io/namespaced-config
TODOs: (either here or separate issues)
request
can be changed after creation. The SyncObjects method won't work if it usesUpdate()
and switching toPatch()
fails for reasons I don't fully understand yet (likely due to dealing with runtime.Object)request
and no limit is supplied. Should we allow the configmap to define both request and limit?What issues does this PR fix or reference?
Closes #477
Is it tested? How?
Create a configmap to set defaults for a specific namespace:
and then create a DevWorkspace in that namespace.
If the namespace already has a claim-devworkspace, it will not be updated and so should be deleted before testing.
PR Checklist
/test v7-devworkspaces-operator-e2e, v7-devworkspace-happy-path
to trigger)v7-devworkspaces-operator-e2e
: DevWorkspace e2e testv7-devworkspace-happy-path
: DevWorkspace e2e test