[
https://issues.apache.org/jira/browse/AURORA-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400744#comment-15400744
]
David McLaughlin commented on AURORA-1721:
------------------------------------------
If there are shortcomings in Aurora that we can solve in generic ways (adding
the ability to explicitly force the update state machine into ROLLING_BACK is a
great example of this) that could potentially benefit all users of Aurora let's
do that!
But it is not good engineering practice to fit square pegs into round holes
just for one use case, and we have a responsibility to make sure the project
doesn't move forward like that.
The obvious question I would have is - you own this workflows tool right? Why
can't you modify that for your use case?
> Support user initiated rollback
> --------------------------------
>
> Key: AURORA-1721
> URL: https://issues.apache.org/jira/browse/AURORA-1721
> Project: Aurora
> Issue Type: Task
> Components: Scheduler
> Reporter: Igor Morozov
> Assignee: Igor Morozov
> Labels: Uber
> Fix For: 0.16.0
>
>
> The proposal to support user initiated rollback:
> 1. Create new thrift API:
> /**Rollback job update. */
> Response rollbackJobUpdate(
> /** The update to rollback. */
> 1: JobUpdateKey key,
> /** A user-specified message to include with the induced job update
> state change. */
> 3: string message)
> 2. Implement new API in a scheduler so the implementation would just undo
> the latest JobUpdate effectively trying to apply initialState to the job. If
> that is for some reason is impossible them rollback with fail with
> appropriate error message.
> 3. Support new aurora client command 'rollback'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
