- added @ID annotations for all API routes to populate operationId Swagger attribute
- split GetWorkspacesHandler into 2 separate handlers to account for @ID needing to be unique-per-route
- GetAllWorkspacesHandler now services GET /workspaces
- GetWorkspacesByNamespaceHandler now services GET /workspaces/{namespace}
- non-exported getWorkspacesHandler function contains all business logic that existed in GetWorkspacesHandler
- Adjusted test cases to align with the new handler names.
Signed-off-by: Andy Stoneberg <astonebe@redhat.com>
related: #298
- Added PauseActionWorkspaceHandler to handle pausing or unpausing a given workspace
- Introduced single new route for starting and pausing workspaces in the API.
- `api/v1/workspaces/{namespace}/{name}/actions/pause`
- pausing or unpausing operation is specified in the request payload
- Created a new WorkspaceActionPauseEnvelope type for successful responses.
- Leveraging JSONPatch / client.RawPatch to ensure Workspace in "valid state" before attempting action
- for `start`: `spec.paused` must be `true`, and `status.state` must be `Paused`
- for `pause`: `spec.paused` must be `false`
- note: I would love to have a `status.state` check here of `status.state != Paused`, but that type of comparison is not supported in [JSONPatch](https://datatracker.ietf.org/doc/html/rfc6902#section-4.6)
- Added tests for the new API, including success and error cases.
- Updated README/OpenAPI documentation to include the new endpoints.
---
As an interesting "edge case" worth calling out, the following payload is currently honored by the API:
```
{
"data": {}
}
```
Given the `WorkspaceActionPause` struct is simply `{"paused": true|false}`, the "empty" Envelope presented above deserializes the JSON using the zero value of `bool` (which is `false`).
Our validation today is always performed against the **deserialized** object, and as such impossible to distinguish the following cases:
```
{
"data": {}
}
```
vs
```
{
"data": {
"paused": false
}
}
```
The effort and (relative) complexity to prevent this and return a `422` in this scenario was not deemed "worth it" for the time being. As a result, a test case has been added for this specific scenario to at minimum document this "strange" behavior.
- Clients, however, should **NOT** rely on this behavior and always provide a fully defined `WorkspaceActionPause` JSON object to ensure future compatibility.
Signed-off-by: Andy Stoneberg <astonebe@redhat.com>
related: #239
This commit brings partial support for secrets to the backend API. It enables the `frontend` component to successfully create a Workspace through the "wizard flow".
**HOWEVER**, it is important to note this secrets attribute is not supported within the `controller` component yet - as #240 is not yet merged. To unblock the `frontend` - the logic contained in this commit simply adds the necessary scaffolding to accept the `secrets` attribute defined within `volumes`. Once umarshalled, the backend essentially ignores this data. Code to fully enable the end to end flow is included in this PR - but simply commented out with `TODO:` comments denoting what can be uncommented once #240 is merged into `notebooks-v2`. A test is also presently disabled with `XIt` - and can also be enabled when required code present.
Changes were initially coded against the branch provided on #240 to verify full end-to-end behavior. Once confirmed, commit was rebased onto `notebooks-v2`, relevant code commented out as described above, and behavior retested to ensure desired outcome.
In summary, with these changes:
- `backend` API accepts `volumes.secrets` in the _Create_ payload
- secrets data is **NOT USED** when programmatically constructing the Workspace CR
- Resultant workspace has no `secrets` data - irrespective of it if was provided in the payload or not.
Signed-off-by: Andy Stoneberg <astonebe@redhat.com>
Andy Stoneberg
Andy Stoneberg
Roee Afriat
asaadbalum
Liav Weiss
Mohamed