[SLO] Create SLO with specified ID

[kdelemme]

📝 Summary

When creating an SLO, we should allow an optional ID to be specified, and use this ID for the SLO.
When not specified, we should fallback to a uuidv1 as we currently do.

The optional ID should be length limited to avoid problematic usage when used in the related transform ID.

To simplify SLO management through infrastructure as code, we should allow the creation of an SLO with a custom id instead of relying on a uuidv1 generated on the server.

This change requires a few changes in the repository and the schema:

• Saving an SLO requires first to find any existing SLO by it's attributes.id, then overwrite it (update) or save a new one
• Find an SLO by ID requires to use the find api with attributes.id
• Delete an SLO by ID requires to first find the SLO and then deletes it.

When creating an SLO, if an existing SLO already exists for the given id, we should return a 409 conflict.
The SLO id schema should be enforced with at least a 8-char alphanumerical string, up to 32-char.

✅ Acceptance criteria

• If the same ID already exists, the API should reject with 400 "ID already exists"
• On the UI, throw a nice error toast

[elasticmachine]

Pinging @elastic/actionable-observability (Team: Actionable Observability)

[kdelemme]

@CoenWarmer you've added this. Are we sure that's the expected behaviour we want?

If the same ID already exists, the API should reject with 400 "ID already exists"
On the UI, throw a nice error toast

Our UI does not provide a way to specify an id, It's only an API details for external (e.g. terraform) client. Therefore, we don't need to handle this case in our UI (yet, maybe never).

For the 400, not sure it's the preferred response for idempotent request. Maybe a 409, but probably more a 200/201. Basically, the responsibility of choosing a unique identifier is on the client, then the server treats the request as a no-op if it already exists, or create the slo if it does not. @wandergeek can shed some light here.

[CoenWarmer]

@CoenWarmer you've added this. Are we sure that's the expected behaviour we want?

If the same ID already exists, the API should reject with 400 "ID already exists"
On the UI, throw a nice error toast

Our UI does not provide a way to specify an id, It's only an API details for external (e.g. terraform) client. Therefore, we don't need to handle this case in our UI (yet, maybe never).

For the 400, not sure it's the preferred response for idempotent request. Maybe a 409, but probably more a 200/201. Basically, the responsibility of choosing a unique identifier is on the client, then the server treats the request as a no-op if it already exists, or create the slo if it does not. @wandergeek can shed some light here.

Hey @kdelemme, this is what was suggested while discussing this ticket in the Inbox session while you were out. We tried to interpret the use case on the basis of the description. And we (apparently incorrectly) assumed the UI implications. Feel free to adjust the acceptance criteria how you see fit.

[wandergeek]

For the 400, not sure it's the preferred response for idempotent request. Maybe a 409, but probably more a 200/201. Basically, the responsibility of choosing a unique identifier is on the client, then the server treats the request as a no-op if it already exists, or create the slo if it does not. @wandergeek can shed some light here.

Thanks for this @kdelemme, I really appreciate it. Part of me thinks a 400/409 is preferable because if someone accidentally use the create API when they should've used the update API, they could be lead into a false sense that the request worked when it didn't.

Edit: Which looks like that's exactly what you did. Perfect!