[openstack-dev] [savanna] savannaclient v2 api
Alexander Ignatov
aignatov at mirantis.com
Thu Jan 16 13:10:25 UTC 2014
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 <matt at redhat.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list