[
https://issues.apache.org/jira/browse/AURORA-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335233#comment-15335233
]
David McLaughlin commented on AURORA-1711:
------------------------------------------
In our case it's not about correctness (our tool can continue because
eventually we eventually detect a no-op update), but it's about auditing and
tracking. We want to make sure that the action is recorded and remove confusion
to users.
Example of user experience right now:
1) User clicks the update button for a given job key
2) The request to the Scheduler times out, so we propagate the error to the user
3) User sees a "Update failed" message in the UI/API
4) User tries again, gets a "Update in progress" message.
5) User is confused for the duration of their update.
6) Eventually the update completes and our system lets them skip over the
'no-op' update.
7) Another user comes along and wonders why a given release was skipped.
Also if you replace the user with an automated orchestration agent, it becomes
even more important to be able to reconcile the state.
> Allow client to store metadata on Update entity
> -----------------------------------------------
>
> Key: AURORA-1711
> URL: https://issues.apache.org/jira/browse/AURORA-1711
> Project: Aurora
> Issue Type: Task
> Components: Scheduler
> Reporter: David McLaughlin
>
> I have a use case where I'm programmatically starting updates via the Aurora
> API and sometimes the request to the scheduler times out or fails, even
> though the update is written to storage and started.
> I'd like to be able to store some unique identifier on the update so that we
> can reconcile this state later. We can make this generic by allowing clients
> to store arbitrary metadata on an update (similar to how they do it with job
> configuration).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
