Open Stack

On Sun, Jan 19, 2014 at 7:53 AM, Matthew Farrellee <matt at redhat.com> wrote:

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

[AL] I like to disable 'periodic' in dev environment. And this is the only
way to update job status without periodic.
So, I vote on adding it to savannaclient and to horizon.


>
>
>  ----
>> 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?
>

[AL] I can easily imagine scenario where canceling is useful.

Both features give some benefit, but not extremely needed. So, it is a
question of priorities. My vote is on leaving both of them.



>
>
> 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
>>
>>
>
> _______________________________________________
> 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/20140119/82be03a5/attachment.html>