[
https://issues.apache.org/jira/browse/AURORA-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335073#comment-15335073
]
Maxim Khutornenko commented on AURORA-1711:
-------------------------------------------
I am afraid there is no easy way to verify that the "in progress" update is the
one that was originally requested. I mean, it could be that update A was fired
but no response was received. Then it finished and the update B was quickly
issued afterward. Relying on "in progress" here would not make sense as A <> B.
I can see how this metadata could be useful for storing custom tags that could
be used by deploy client to support broader, cross-cluster deployment cases.
Would you mind giving a bit more details to the nature of your concern here?
> 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)
