++ for generic PUT for both ‘cancel’ and ‘refresh-status’, Andrew. Thanks!
Regards, Alexander Ignatov On 17 Jan 2014, at 06:19, Andrey Lazarev <[email protected]> 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. > > > ---- > 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). > > > Thanks, > Andrew. > > > On Thu, Jan 16, 2014 at 5:10 AM, Alexander Ignatov <[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]> 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] > > 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
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
