aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua Cohen (JIRA)" <>
Subject [jira] [Commented] (AURORA-1711) Allow client to store metadata on Update entity
Date Mon, 15 Aug 2016 17:00:24 GMT


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

> Allow client to store metadata on Update entity
> -----------------------------------------------
>                 Key: AURORA-1711
>                 URL:
>             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

View raw message