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

Maxim Khutornenko commented on AURORA-1711:
-------------------------------------------

I think saving an extra read-only RPC call in case of a failed 
{{startJobUpdate}} call is a questionable tradeoff here. The rate of 
{{startJobUpdate}} calls is incomparable to UI and other aurora client 
auto-retry pulls we already have in the system.

We can further improve and save an extra call by extending the 
{{StartJobUpdateResult}} to have an optional metadata or the entire 
{{JobUpdate}} object with the in-progress update details. That said, I feel 
relying on an occasional {{getJobUpdateDetails}} call placed *only* in case of 
a failed {{startJobUpdate}} should be sufficient 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)

Reply via email to