Open Stack

(inline-ish)

On 01/20/2014 02:36 AM, Andrey Lazarev wrote:
>
>
>
> On Sun, Jan 19, 2014 at 7:53 AM, Matthew Farrellee <matt at redhat.com
> <mailto:matt at redhat.com>> wrote:
>
>     On 01/16/2014 09:19 PM, Andrey Lazarev wrote:

>         ----
>         REMOVE -
>         @rest.get('/job-executions/<__job_execution_id>/refresh-__status')
>         - refresh
>         and return status - GET should not side-effect, status is part of
>         details and
>         updated periodically, currently unused
>         ----
>         This call goes to Oozie directly to ask it about job status. It
>         allows
>         not to wait
>         too long when periodic task will update status JobExecution
>         object in
>         Savanna.
>         The current GET asks status of JobExecution from savanna-db. I
>         think we can
>         leave this call, it might be useful for external clients.
>         ----
>         [AL] Agree that GET shouldn't have side effect (or at least
>         documented
>         side effect). I think it could be generic PUT on
>         '/job-executions/<job___execution_id>' which can refresh status
>         or cancel
>         job on hadoop side.
>
>
>      From what I can tell, this endpoint is not exposed by the
>     savannaclient or used directly from the horizon plugin.
>
>     I imagine that having a "savanna-api, please go faster" call is
>     enticing, but if we're not using it yet, let's make sure we have a
>     well defined need before adding/keeping it.
>
> [AL] I like to disable 'periodic' in dev environment. And this is the
> only way to update job status without periodic.
> So, I vote on adding it to savannaclient and to horizon.

IMHO, we should not be adding calls to the client or horizon app that 
would use this command. Instead we should have a well tuned periodic 
value that meets user expectations.

I propose we not expose this as part of the official Savanna API, and we 
look into other options for developer environments that allow for 
triggering a refresh of oozie information. Possibly when savanna-api 
gets a SIGUSR1 it should re-run all periodic tasks?



>         ----
>         REMOVE -
>         @rest.get('/job-executions/<__job_execution_id>/cancel') - cancel
>         job-execution - GET should not side-effect, currently unused,
>         use DELETE /job/executions/<job___execution_id>
>         ----
>         Disagree. We have to leave this call. This methods stops job
>         executing
>         on the
>         Hadoop cluster but doesn't remove all its related info from
>         savanna-db.
>         DELETE removes it completely.
>         ----
>         [AL] We need 'cancel'. Vote on generic PUT (see previous item).
>
>
>     AFAICT, this is also not used. Where is the need?
>
>
> [AL] I can easily imagine scenario where canceling is useful.
>
> Both features give some benefit, but not extremely needed. So, it is a
> question of priorities. My vote is on leaving both of them.

I don't disagree that we could come up with scenarios, but we should not 
add these to the Savanna API until we have concrete scenarios to 
implement in the horizon app or CLI.

Best,


matt