<div dir="ltr"><div>My 5 cents:</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">------</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">REMOVE - @rest.put('/node-group-</span><span style="font-family:arial,sans-serif;font-size:13px">templates/<node_group_</span><span style="font-family:arial,sans-serif;font-size:13px">template_id>') - Not Implemented</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">REMOVE - @rest.put('/cluster-templates/</span><span style="font-family:arial,sans-serif;font-size:13px"><cluster_template_id>') - Not Implemented</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">------</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Disagree with that. Samsung people did great job in both savanna/savanna-dashboard</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">to make this implemented [2], [3]. We should leave and support these calls in savanna.</span><br></div><div><span style="font-size:13px;font-family:arial,sans-serif">------</span><br style="font-size:13px;font-family:arial,sans-serif">
</div><div><span style="font-size:13px;font-family:arial,sans-serif">[AL] Agree with Alexander. Ability to modify templates is very useful feature.</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">----</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">REMOVE - @rest.get('/job-executions/<</span><span style="font-family:arial,sans-serif;font-size:13px">job_execution_id>/refresh-</span><span style="font-family:arial,sans-serif;font-size:13px">status') - refresh</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">and return status - GET should not side-effect, status is part of details and</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">updated periodically, currently unused</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">----</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">This call goes to Oozie directly to ask it about job status. It allows not to wait</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">too long when periodic task will update status JobExecution object in Savanna.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">The current GET asks status of JobExecution from savanna-db. I think we can</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">leave this call, it might be useful for external clients.</span></div><div>----</div><div><span style="font-family:arial,sans-serif;font-size:13px">[AL] Agree that GET shouldn't have side effect (or at least documented side effect). I think it could be generic PUT on </span><span style="font-size:13px;font-family:arial,sans-serif">'/job-executions/<</span><span style="font-size:13px;font-family:arial,sans-serif">job_execution_id>' which can refresh status or cancel job on hadoop side.</span></div>
<div><br></div><div><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">----</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">REMOVE - @rest.get('/job-executions/<</span><span style="font-family:arial,sans-serif;font-size:13px">job_execution_id>/cancel') - cancel</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">job-execution - GET should not side-effect, currently unused,</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">use DELETE /job/executions/<job_</span><span style="font-family:arial,sans-serif;font-size:13px">execution_id></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">----</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Disagree. We have to leave this call. This methods stops job executing on the</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">Hadoop cluster but doesn't remove all its related info from savanna-db.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">DELETE removes it completely.</span><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><div>----</div><div><span style="font-family:arial,sans-serif;font-size:13px">[AL] We need 'cancel'. Vote on generic PUT (see previous item).</span></div></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><br></div>Thanks,<div>Andrew.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 5:10 AM, Alexander Ignatov <span dir="ltr"><<a href="mailto:aignatov@mirantis.com" target="_blank">aignatov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matthew,<br>
<br>
I'm ok with proposed solution. Some comments/thoughts below:<br>
<br>
---------<br>
FIX - @rest.post_file('/plugins/<plugin_name>/<version>/convert-config/<name>')<br>
- this is an RPC call, made only by a client to do input validation,<br>
move to POST /validations/plugins/:name/:version/check-config-import<br>
---------<br>
AFAIR, this rest call was introduced not only for validation.<br>
The main idea was to create method which converts plugin specific config<br>
for cluster creation to savanna's cluster template [1]. So maybe we may change<br>
this rest call to: /plugins/convert-config/<name> and include all need fields<br>
to "data". Anyway we have to know Hortonworks guys opinion. Currently HDP<br>
plugin implements this method only.<br>
<br>
------<br>
REMOVE - @rest.put('/node-group-templates/<node_group_template_id>') - Not Implemented<br>
REMOVE - @rest.put('/cluster-templates/<cluster_template_id>') - Not Implemented<br>
------<br>
Disagree with that. Samsung people did great job in both savanna/savanna-dashboard<br>
to make this implemented [2], [3]. We should leave and support these calls in savanna.<br>
<br>
------<br>
CONSIDER rename /jobs -> /job-templates (consistent w/ cluster-templates & clusters)<br>
CONSIDER renaming /job-executions to /jobs<br>
-------<br>
Good idea!<br>
<br>
------<br>
FIX - @rest.get('/jobs/config-hints/<job_type>') - should move to<br>
GET /plugins/<plugin_name>/<plugin_version>, similar to get_node_processes<br>
and get_required_image_tags<br>
------<br>
Not sure if it should be plugin specific right now. EDP uses it to show some<br>
configs to users in the dashboard. it's just a cosmetic thing. Also when user<br>
starts define some configs for some job he might not define cluster yet and<br>
thus plugin to run this job. I think we should leave it as is and leave only<br>
abstract configs like Mapper/Reducer class and allow users to apply any<br>
key/value configs if needed.<br>
<br>
-----<br>
CONSIDER REMOVING, MUST ALWAYS UPLOAD TO Swift FOR /job-binaries<br>
-----<br>
Disagree. It was discussed before starting EDP implementation that there are<br>
a lot of OS installations which don't have Swift deployed, and ability to run<br>
jobs using savanna internal db is a good option in this case. But yes, Swift<br>
is more preferred. Waiting for Trevor's and maybe Nadya's comments here under<br>
this section.<br>
<br>
----<br>
REMOVE - @rest.get('/job-executions/<job_execution_id>/refresh-status') - refresh<br>
and return status - GET should not side-effect, status is part of details and<br>
updated periodically, currently unused<br>
----<br>
This call goes to Oozie directly to ask it about job status. It allows not to wait<br>
too long when periodic task will update status JobExecution object in Savanna.<br>
The current GET asks status of JobExecution from savanna-db. I think we can<br>
leave this call, it might be useful for external clients.<br>
<br>
----<br>
REMOVE - @rest.get('/job-executions/<job_execution_id>/cancel') - cancel<br>
job-execution - GET should not side-effect, currently unused,<br>
use DELETE /job/executions/<job_execution_id><br>
----<br>
Disagree. We have to leave this call. This methods stops job executing on the<br>
Hadoop cluster but doesn't remove all its related info from savanna-db.<br>
DELETE removes it completely.<br>
<br>
[1] <a href="http://docs.openstack.org/developer/savanna/devref/plugin.spi.html#convert-config-plugin-name-version-template-name-cluster-template-create" target="_blank">http://docs.openstack.org/developer/savanna/devref/plugin.spi.html#convert-config-plugin-name-version-template-name-cluster-template-create</a><br>

[2] <a href="https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template" target="_blank">https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template</a><br>
[3] <a href="https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template" target="_blank">https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template</a><br>
<br>
Regards,<br>
Alexander Ignatov<br>
<br>
<br>
<br>
On 14 Jan 2014, at 21:24, Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>> wrote:<br>
<br>
> <a href="https://blueprints.launchpad.net/savanna/+spec/v2-api" target="_blank">https://blueprints.launchpad.net/savanna/+spec/v2-api</a><br>
><br>
> I've finished a review of the v1.0 and v1.1 APIs with an eye to making them more consistent and RESTful.<br>
><br>
> Please use this thread to comment on my suggestions for v1.0 & v1.1, or to make further suggestions.<br>
><br>
> Best,<br>
><br>
><br>
> matt<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>