(inline-ish)
On 01/20/2014 02:36 AM, Andrey Lazarev wrote:
On Sun, Jan 19, 2014 at 7:53 AM, Matthew Farrellee <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
