Open Stack

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 <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> 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140116/d2cb642f/attachment-0001.html>