[deployments] Restore DELETE /deployments/devices/{id}

Description

We moved this endpoint from management to internal, because it is part of the decommissioning workflow. This breaks API back-compatibility, though, and one of our customers reported it.

We decided to implement the end-point again, in the proper way:

  • Mark all pending device deployments as "aborted"

  • Loop over active deployments (static and dynamic) and, if the device matches, mark the device deployment as "aborted"

Affects versions

None

Environment

None

Checklist

Activity

Show:

eystein.maloy.stenbergDecember 1, 2021 at 9:46 PM

Yes, that sounds good

I don't think we can delete future deployments anyway, regardless if they are static or dynamic. At least I would not expect that if I was using this feature.

Krzysztof JaśkiewiczDecember 1, 2021 at 8:02 PM

Stopping device from getting older dynamic deployments (older than the delete request) looks quite simple, so if this is desired behavior we can simply implement it that way.

what's your opinion on that?

eystein.maloy.stenbergDecember 1, 2021 at 7:54 PM

OK! I would not worry about that case (inventory changes).
Just aborting from the known deployments and known inventory should cover most if not all cases. We should add a note about this in the API though.

Krzysztof JaśkiewiczDecember 1, 2021 at 7:49 PM

I'm OK with applying it to dynamic deployment too, but I have a question (actually it was a Fabio's question for me):
If we'll go through existing deployments, we can evaluate if the device matches or not, and then abort. What if the device inventory changes and it then matches an old dynamic deployment? Are we considering it as one that we should have aborted, or a "new one" for this device?

Fixed

Details

Assignee

Reporter

Labels

Story Points

Priority

Days in progress

0

Fix versions

Sprint

Backlog

yes

Zendesk Support

Checklist

Created December 1, 2021 at 2:59 PM
Updated December 13, 2021 at 8:32 AM
Resolved December 13, 2021 at 8:31 AM