You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@aurora.apache.org by "Bill Farner (JIRA)" <ji...@apache.org> on 2016/06/17 00:06:05 UTC

[jira] [Commented] (AURORA-1711) Allow client to store metadata on Update entity

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

Bill Farner commented on AURORA-1711:
-------------------------------------

{quote}
I'd like to be able to store some unique identifier on the update so that we can reconcile this state later
{quote}

Ideally we would lean on idempotent operations to eliminate this kind of issue.  Would it help, for example, if you could reconstruct the desired state of a job update and compare it to the desired state of the update you intend to commence?  Or, more simply, can you re-issue the {{startJobUpdate}} request and assume it was a duplicate if the response indicates that an update is already in progress?

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