++  for generic PUT for both ‘cancel’ and ‘refresh-status’, Andrew. Thanks!

Regards,
Alexander Ignatov



On 17 Jan 2014, at 06:19, Andrey Lazarev <alaza...@mirantis.com> 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 <aigna...@mirantis.com> 
> 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 <m...@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@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to