Change Details

* Only `/deploy` POST endpoint accepting the above simplified yaml, see if we can express easily the data structure in openapi definition, otherwise accept anything and validate internally * The generated 'intended' model is stored in k8s as a custom resource, in the namespace of the tool (users must be able consult it but not modify it directly) * We will have to interact with the build service, we can explore if we can start with bare http calls, but eventually we will want to reuse the libraries generated from the unified openapi def * This might require being able to trigger builds for other user's projects (as opposed to the current "only your user" auth setup), might require changes on builds-api authentication * We will have to interact with k8s to persist the configuration

[] Create skeleton repository (copy one of the ones we have already) [] Add a webservice using fastapi with: [] `/tool/<toolname>/deploy` POST endpoint that accepts the minimal yaml defined in {T362070} - try to specify the datastructure using pydantic (and expose in the openapi.yaml if possible) [] stores it as configuration (using a specific k8s CRD, stored in the tool namespace, without user read-only permission), try to use typed libraries to interact with k8s [] starts the builds for the configured ones - explore how to interact with the build service (if there, try to use generated libs from the consolidated API, otherwise we will migrate later) [] generates the openapi.yaml file from the webservice (for now), we can add a check on CI to ensure it's updated Note the `<toolname>` in the path, currently we will just check that the user (as passed in the ssl header) is the same as the tool in the path, but this opens allowing to deploy a tool from a different user once we have proper user auth.

* Only `/deploy` POST endpoint accepting the above simplified yaml, see if we can express easily the data structure in openapi definition, otherwise accept anything and validate internally[] Create skeleton repository (copy one of the ones we have already) * The generated 'intended' model is stored in k8s as a custom resource, in the namespace of the tool (users must be able consult it but not modify it directly)[] Add a webservice using fastapi with: * We will have to interact with the build service, we can explore if we can start with bare http calls, but eventually we will want to reuse the libraries generated from the unified openapi def [] `/tool/<toolname>/deploy` POST endpoint that accepts the minimal yaml defined in {T362070} - try to specify the datastructure using pydantic (and expose in the openapi.yaml if possible) * This might require being able to trigger builds for other user's projects (as opposed to the current "only your user" auth setup [] stores it as configuration (using a specific k8s CRD, stored in the tool namespace, without user read-only permission), might require changes on builds-api authenticationtry to use typed libraries to interact with k8s * We will have to interact with k8s to persist the configuration [] starts the builds for the configured ones - explore how to interact with the build service (if there, try to use generated libs from the consolidated API, otherwise we will migrate later) [] generates the openapi.yaml file from the webservice (for now), we can add a check on CI to ensure it's updated Note the `<toolname>` in the path, currently we will just check that the user (as passed in the ssl header) is the same as the tool in the path, but this opens allowing to deploy a tool from a different user once we have proper user auth.