[
https://issues.apache.org/jira/browse/AURORA-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421363#comment-15421363
]
Joshua Cohen commented on AURORA-1711:
--------------------------------------
My concern is that if we want to support this in the client (and I feel
strongly that we should), then we're always going to make this query when
starting a job update (or at the very least, we'll always make this query when
retrying a failed {{startJobUpdate}} call). Given that, it seems beneficial to
me to incorporate this directly into the scheduler. Imagine the scenario where
the scheduler is failing the {{startJobUpdate}} request for reasons other than
a network partition, e.g. for whatever reason it's overloaded. If the client
always responds to that failure by first querying to see if the update it's
trying to launch is in progress and *then* retries the {{startJobUpdate}} call
that's only going to exacerbate the underlying load on the scheduler. Whereas
if the scheduler performs this check implicitly if the client-update-id is set
on the {{JobUpdateRequest}} the process can be better optimized and avoid the
overhead of an unnecessary RPC.
> 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)
