[ 
https://issues.apache.org/jira/browse/AURORA-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421267#comment-15421267
 ] 

Joshua Cohen commented on AURORA-1711:
--------------------------------------

Does forcing the client to make the query become unnecessarily expensive? The 
aurora command line client can also benefit from this logic in the scenario 
where you're accessing the API through a proxy (e.g. the {{startUpdateRequest}} 
cal is sent through the proxy to the scheduler, the update begins, but for 
whatever reason the proxy times out the request to the client, at which point 
the client automatically retries the request and gets an error about the update 
already being in progress). In that scenario, the client will essentially 
*always* make the query to see if the update is active, so why not just have 
the scheduler implicitly make the check when processing a {{startJobUpdate}} 
request that includes the metadata? I think it would also makes sense, in this 
case, to move away from a generic "metadata" field and towards an explicit 
"client update identifier" field so that the scheduler is not enforcing its own 
meaning on what from the outside appears to be data whose purpose should be 
unknown to the scheduler.

> 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)

Reply via email to