<div dir="ltr">Inlined.<div><br></div><div>Thanks,</div><div>Andrew.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 19, 2014 at 7:50 AM, Matthew Farrellee <span dir="ltr"><<a href="mailto:matt@redhat.com" target="_blank">matt@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/16/2014 08:10 AM, Alexander Ignatov 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/<<u></u>plugin_name>/<version>/<u></u>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/:<u></u>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>
</blockquote>
<br>
The case of converting savanna cluster templates to plugin specific can be done internally, i.e. w/o exposing an API call. The Savanna API should talk savanna cluster templates only.<br>
<br>
ACAICT, that leaves the validation justification for exposing it, so possibly a move to a /validations namespace.<br></blockquote><div><br></div><div>[AL] +1 on moving to /validations</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
------<br>
REMOVE - @rest.put('/node-group-<u></u>templates/<node_group_<u></u>template_id>') - Not Implemented<br>
REMOVE - @rest.put('/cluster-templates/<u></u><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>
</blockquote>
<br>
Absolutely. Now that they're implemented they should not be removed.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
------<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/<u></u><job_type>') - should move to<br>
GET /plugins/<plugin_name>/<<u></u>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>
</blockquote>
<br>
FYI, the code contains comments suggesting it should be plugin specific.<br>
<br>
<a href="https://github.com/openstack/savanna/blob/master/savanna/service/edp/workflow_creator/workflow_factory.py#L179" target="_blank">https://github.com/openstack/<u></u>savanna/blob/master/savanna/<u></u>service/edp/workflow_creator/<u></u>workflow_factory.py#L179</a><br>

<br>
IMHO, the EDP should have no plugin specific dependencies.<br>
<br>
If it currently does, we should look into why and see if we can't eliminate this entirely.<br>
<br></blockquote><div>[AL] EDP uses plugins in two ways:</div><div>1. for HDFS user</div><div>2. for config hints</div><div>I think both items should not be plugin specific on EDP API level. But implementation should go to plugin and call plugin API for result.</div>
<div>   <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----<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>
</blockquote>
<br>
While it's true that you can deploy OS w/o Swift, it's ok for us to start preferring deployments w/ Swift.<br>
<br></blockquote><div>[AL] +1 on change default value in horizon, but don't change anything in API. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Best,<br>
<br>
<br>
matt<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----<br>
REMOVE - @rest.get('/job-executions/<<u></u>job_execution_id>/refresh-<u></u>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/<<u></u>job_execution_id>/cancel') - cancel<br>
job-execution - GET should not side-effect, currently unused,<br>
use DELETE /job/executions/<job_<u></u>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/<u></u>developer/savanna/devref/<u></u>plugin.spi.html#convert-<u></u>config-plugin-name-version-<u></u>template-name-cluster-<u></u>template-create</a><br>

[2] <a href="https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template" target="_blank">https://blueprints.launchpad.<u></u>net/savanna/+spec/modifying-<u></u>cluster-template</a><br>
[3] <a href="https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template" target="_blank">https://blueprints.launchpad.<u></u>net/savanna/+spec/modifying-<u></u>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" target="_blank">matt@redhat.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://blueprints.launchpad.net/savanna/+spec/v2-api" target="_blank">https://blueprints.launchpad.<u></u>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>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div></div>