On 01/16/2014 09:19 PM, Andrey Lazarev wrote:
My 5 cents:
------
REMOVE - @rest.put('/node-group-templates/<node_group_template_id>') -
Not Implemented
REMOVE - @rest.put('/cluster-templates/<cluster_template_id>') - Not
Implemented
------
Disagree with that. Samsung people did great job in both
savanna/savanna-dashboard
to make this implemented [2], [3]. We should leave and support these
calls in savanna.
------
[AL] Agree with Alexander. Ability to modify templates is very useful
feature.
----
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.
----
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?
Best,
matt
Thanks,
Andrew.
On Thu, Jan 16, 2014 at 5:10 AM, Alexander Ignatov
<[email protected] <mailto:[email protected]>> wrote:
Matthew,
I'm ok with proposed solution. Some comments/thoughts below:
---------
FIX -
@rest.post_file('/plugins/<plugin_name>/<version>/convert-config/<name>')
- this is an RPC call, made only by a client to do input validation,
move to POST /validations/plugins/:name/:version/check-config-import
---------
AFAIR, this rest call was introduced not only for validation.
The main idea was to create method which converts plugin specific config
for cluster creation to savanna's cluster template [1]. So maybe we
may change
this rest call to: /plugins/convert-config/<name> and include all
need fields
to "data". Anyway we have to know Hortonworks guys opinion.
Currently HDP
plugin implements this method only.
------
REMOVE - @rest.put('/node-group-templates/<node_group_template_id>')
- Not Implemented
REMOVE - @rest.put('/cluster-templates/<cluster_template_id>') - Not
Implemented
------
Disagree with that. Samsung people did great job in both
savanna/savanna-dashboard
to make this implemented [2], [3]. We should leave and support these
calls in savanna.
------
CONSIDER rename /jobs -> /job-templates (consistent w/
cluster-templates & clusters)
CONSIDER renaming /job-executions to /jobs
-------
Good idea!
------
FIX - @rest.get('/jobs/config-hints/<job_type>') - should move to
GET /plugins/<plugin_name>/<plugin_version>, similar to
get_node_processes
and get_required_image_tags
------
Not sure if it should be plugin specific right now. EDP uses it to
show some
configs to users in the dashboard. it's just a cosmetic thing. Also
when user
starts define some configs for some job he might not define cluster
yet and
thus plugin to run this job. I think we should leave it as is and
leave only
abstract configs like Mapper/Reducer class and allow users to apply any
key/value configs if needed.
-----
CONSIDER REMOVING, MUST ALWAYS UPLOAD TO Swift FOR /job-binaries
-----
Disagree. It was discussed before starting EDP implementation that
there are
a lot of OS installations which don't have Swift deployed, and
ability to run
jobs using savanna internal db is a good option in this case. But
yes, Swift
is more preferred. Waiting for Trevor's and maybe Nadya's comments
here under
this section.
----
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.
----
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.
[1]
http://docs.openstack.org/developer/savanna/devref/plugin.spi.html#convert-config-plugin-name-version-template-name-cluster-template-create
[2]
https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template
[3]
https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template
Regards,
Alexander Ignatov
On 14 Jan 2014, at 21:24, Matthew Farrellee <[email protected]
<mailto:[email protected]>> wrote:
> https://blueprints.launchpad.net/savanna/+spec/v2-api
>
> I've finished a review of the v1.0 and v1.1 APIs with an eye to
making them more consistent and RESTful.
>
> Please use this thread to comment on my suggestions for v1.0 &
v1.1, or to make further suggestions.
>
> Best,
>
>
> matt
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
<mailto:[email protected]>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
