Skip to content

Remove the Java onboarding in favor of the onboarding API #696

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.

Sign up for GitHub

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

Open
ddecrulle wants to merge 1 commit into
base: mode-serviceaccount-in-target-namespace
Choose a base branch
from
+22 −689
Open

Remove the Java onboarding in favor of the onboarding API #696

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 0 additions & 11 deletions docs/SPECIFICATION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,17 +45,6 @@ My Lab endpoints are available to authenticated users, offering a programmatic w

The endpoints routed by `fr.insee.onyxia.api.controller.api.mylab.QuotaController`, are only functional if a quota feature is set on the Region, and allow users to:
- `GET /my-lab/quota` get their quota on the namespace, which is implemented by a quota resource with the name `onyxia-quota`
- `POST /my-lab/quota` change their quota on the namepsace, if quota changing is enabled
- `POST /my-lab/quota/reset` reset their quota to the default one on the namespace

### /onboarding/

The request to onboard process entails the creation of the Kubernetes namespace for the Group and the creation of a RoleBinding to that namespace giving the default ServiceAccount of that namespace admin permissions. There is a check in whether the user that made the request belongs to the group, based on the OIDC token, and the group onboarding process is triggered if so.

*NOTE: this onboarding process is being done behind the scenes when requesting a first service, and the endpoint use is not the default behaviour.*

If no group is given in the body, it is assumed that it is a user onboard, i.e., a namespace for a single user rather than a Group (Project), and the creation of the namespace and RoleBinding remains the same. However, in the user use-case, there is also the possibility to set Quotas on the namespace during creation, and these are obtained in the Region definition configuration.


### /public/
Public endpoints are available to all, offering a programmatic way to comprehend the current configuration and the available services in Onyxia. They allow users to:
Expand Down
34 changes: 6 additions & 28 deletions docs/region-configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,10 +50,6 @@ Users can work on Onyxia as a User or as a Group to which they belong. Each user
| Key | Default | Description | Example |
|-------------------------------| ------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| `type` | | Type of the platform on which services are launched. Only Kubernetes is supported, Marathon has been removed. | "KUBERNETES" |
| `allowNamespaceCreation` | true | **Deprecated**, use the onboarding API instead. If true, the /onboarding endpoint is enabled and the user will have a namespace created on its first request on a service resource. Ignored (forced to false) with `serviceAccountInTargetNamespace` authentication. | true |
| `namespaceLabels` | | Static labels to add to the namespace (at creation and subsequent user logins) | {"zone":"prod"} |
| `namespaceAnnotations` | | Static annotations to add to the namespace (at creation and subsequent user logins) | {"zone":"prod"} |
| `namespaceAnnotationsDynamic` | | Dynamic annotations (currently only based on user JWT token) to add to the namespace (at creation and subsequent user logins). Annotations names will be prefixed with `onyxia_`. `onyxia_last_login_timestamp` is also added. | {"enabled": true, "userAttributes": ["sub", "email"] } |
| `singleNamespace` | true | When true, all users share the same namespace on the service provider. This configuration can be used if a project works on its own Onyxia region. | |
| `userNamespace` | true | When true, all users have a namespace for their work. This configuration can be used if you don't allow a user to have their own space to work and only use project space | |
| `namespacePrefix` | "user-" | User has a personal namespace like namespacePrefix + userId (should only be used when not singleNamespace but not the case) | |
Expand Down Expand Up @@ -92,30 +88,12 @@ It can be used to add additional features to Onyxia. It helps Onyxia users to di

### Quotas properties

When this feature is enabled, Onyxia creates and maintains a [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) in the user / group namespace.
This feature can be enabled for either or both `user` and `group` namespaces and, for user namespaces, quotas can depend on the user roles.

| Key | Default | Description | Example |
|----------------| ------- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ------ |
| `userEnabled` | false | Whether or not `ResourceQuotas` should be created for user namespaces. | true |
| `user` | | Quota to apply to user namespaces. | `{ "count/pods": "5" }` |
| `roles` | | Map of quotas corresponding to user roles. In case the user has multiple of those roles, only the first one will be applied. If user has no role from this list then `user` quota will be applied. | `{"admin": { "count/pods": "999" }}` |
| `groupEnabled` | false | Whether or not `ResourceQuotas` should be created for group namespaces. | true |
| `group` | | Quota to apply to group namespaces. | `{ "count/pods": "5" }` |

A quota follows the Kubernetes model which is composed of:
* "requests.memory"
* "requests.cpu"
* "limits.memory"
* "limits.cpu"
* "requests.storage"
* "count/pods"
* "requests.ephemeral-storage"
* "limits.ephemeral-storage"
* "requests.nvidia.com/gpu"
* "limits.nvidia.com/gpu"

Note : If you want Onyxia to create the ResourceQuota but not override it at each user login / action (e.g you override it yourself for some specific users), you can add the annotation `onyxia_ignore` to the ResourceQuota. If this annotation is set on a ResourceQuota then Onyxia won't touch it anymore.
ResourceQuotas are created by the onboarding API in each namespace. These properties only enable the `GET /my-lab/quota` endpoint, which displays the [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) named `onyxia-quota` of the user / group namespace.

| Key | Default | Description |
|----------------| ------- |----------------------------------------------------------------|
| `userEnabled` | false | Whether or not quotas are displayed for user namespaces. |
| `groupEnabled` | false | Whether or not quotas are displayed for group namespaces. |

### Expose properties

Expand Down
14 changes: 0 additions & 14 deletions ...-api/src/main/java/fr/insee/onyxia/api/configuration/properties/RegionsConfiguration.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,20 +83,6 @@ public void load() throws Exception {
"Using the {} service account of each namespace for region {}.",
region.getServices().getTargetNamespaceServiceAccount(),
region.getId());
if (!region.getServices().isSingleNamespace()
&& region.getServices().isAllowNamespaceCreation()) {
// Namespaces and their service account are created by the onboarding
// API, the API has no permission to do it in this mode
LOGGER.warn(
"Namespace creation is disabled for region {}: the onboarding API must be used with serviceAccountInTargetNamespace authentication.",
region.getId());
region.getServices().setAllowNamespaceCreation(false);
}
} else if (!region.getServices().isSingleNamespace()
&& region.getServices().isAllowNamespaceCreation()) {
LOGGER.warn(
"Namespace creation by Onyxia API (allowNamespaceCreation) is deprecated for region {} and will be removed, use the onboarding API instead.",
region.getId());
}
});
}
Expand Down
102 changes: 0 additions & 102 deletions ...api/src/main/java/fr/insee/onyxia/api/controller/api/onboarding/OnboardingController.java
View file
Open in desktop

This file was deleted.

11 changes: 0 additions & 11 deletions ...rc/main/java/fr/insee/onyxia/api/controller/exception/NamespaceAlreadyExistException.java
View file
Open in desktop

This file was deleted.

11 changes: 0 additions & 11 deletions ...i/src/main/java/fr/insee/onyxia/api/controller/exception/OnboardingDisabledException.java
View file
Open in desktop

This file was deleted.

46 changes: 0 additions & 46 deletions onyxia-api/src/main/java/fr/insee/onyxia/api/events/InitNamespaceEvent.java
View file
Open in desktop

This file was deleted.

Loading
Loading