Open Stack

On 01/16/2014 09:19 PM, Andrey Lazarev 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.

 From what I can tell, this endpoint is not exposed by the savannaclient 
or used directly from the horizon plugin.

I imagine that having a "savanna-api, please go faster" call is 
enticing, but if we're not using it yet, let's make sure we have a well 
defined need before adding/keeping it.


> ----
> 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).

AFAICT, this is also not used. Where is the need?


Best,


matt


> Thanks,
> Andrew.
>
>
> On Thu, Jan 16, 2014 at 5:10 AM, Alexander Ignatov
> <aignatov at mirantis.com <mailto:aignatov at 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 <matt at redhat.com
>     <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>      > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>