[jira] [Commented] (SLIDER-659) NPE in slider am-suicide if you don't provide a message
[
https://issues.apache.org/jira/browse/SLIDER-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219517#comment-14219517
]
ASF subversion and git services commented on SLIDER-659:
Commit 976c889ba04d23222d7f04ab4f50859a4edf122d in incubator-slider's branch
refs/heads/develop from [~ste...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=976c889 ]
SLIDER-659 NPE in slider am-suicide if you don't provide a message: make sure
AM handles null payload
NPE in slider am-suicide if you don't provide a message
---
Key: SLIDER-659
URL: https://issues.apache.org/jira/browse/SLIDER-659
Project: Slider
Issue Type: Bug
Components: client
Affects Versions: Slider 0.60
Reporter: Steve Loughran
Assignee: Steve Loughran
Priority: Minor
Fix For: Slider 0.70
trying to call {{am-suicide}} without a {{--message}} argument triggers an NPE
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLIDER-663) Make it easy to develop and deploy application packages that are essentially shell commands
[ https://issues.apache.org/jira/browse/SLIDER-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219522#comment-14219522 ] Steve Loughran commented on SLIDER-663: --- + a URL to download a tarball from. ...you could have a meta-app-package whose app config params included URL, commands etc. Hard part would be config generation. Make it easy to develop and deploy application packages that are essentially shell commands --- Key: SLIDER-663 URL: https://issues.apache.org/jira/browse/SLIDER-663 Project: Slider Issue Type: Task Components: agent-provider, app-package Affects Versions: Slider 0.60 Reporter: Sumit Mohanty Assignee: Sumit Mohanty Priority: Critical Slider app packages require several artifacts for completeness such as a metainfo.xml, a python script to read config and a python script for life cycle commands, a tarball, etc. A simple application can be modeled as a shell command or as a java application that just needs a jar and some system properties. So the application requirement can be summarized as: * a jar * a command * a small set of properties While it is possible to model these as an application package (e.g. memcached) it is also evident that there are a lot of common patterns that need to be duplicated. Slider should provide a way to pass these parameters in the create call itself rather than having to create a full application package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLIDER-494) Support for short-lived services
[
https://issues.apache.org/jira/browse/SLIDER-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219534#comment-14219534
]
Steve Loughran commented on SLIDER-494:
---
That could work.
Some initial thoughts
# The AM would have to build up some structure of completed instances, maybe
just another counter in the {{RoleStatus}} field.
# It would add more containers until the number of successful completions
matched the number of instances requested.
# status code would come back from the agent.
when a stopped instance is started it would re-run all the commands
where we'd have problems is on AM restart: the restarted AM doesn't remember
anything from the previous instance, so re-execute everything.
Question is: does that matter? We care a lot about AM restart as over a few
weeks it becomes an issue, and on short lived apps the risk is less. We could
even allow app configs to set the option to say don't keep containers over
restarts and the AM retry count itself (which can be set in
{{slider-client.xml}} today, in {{slider.yarn.restart.limit}}. That way, run a
short-lived app and if the AM fails, the app itself halts; no attempt to recover
Support for short-lived services
Key: SLIDER-494
URL: https://issues.apache.org/jira/browse/SLIDER-494
Project: Slider
Issue Type: Bug
Components: app-package, appmaster
Affects Versions: Slider 0.50
Reporter: Sumit Mohanty
Fix For: Slider 2.0.0
Slider applications could be short lived in the sense that the component
instances are not daemons but are processes that stop after they are done.
These processes may also fail in which case they may be auto-restarted or
they can complete gracefully in which case the application instance should
terminate (when all component instances are complete).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLIDER-666) Default configure method for apps
Billie Rinaldi created SLIDER-666: - Summary: Default configure method for apps Key: SLIDER-666 URL: https://issues.apache.org/jira/browse/SLIDER-666 Project: Slider Issue Type: Improvement Components: agent Reporter: Billie Rinaldi Assignee: Sumit Mohanty Fix For: Slider 2.0.0 We have these configFiles specified in app package metainfo with file names and types. It would be nice if there were a default configure method for apps that would create all the configFiles in a specified directory, or in some default directory that could be referenced. One snag I see is for files like accumulo-env.sh and hbase-env.sh. They both have xml config files in metainfo, and the content field in the xml has the actual contents of the .sh file. Maybe this could be a special config file type that just pulls out that content field from the xml and writes it to an .sh file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
I can't specify user by calling Execute method
Hi I specified user when call Execute(..., user='hdp',...) But the container processes are all launched as *yarn* user
Re: I can't specify user by calling Execute method
Actually, user=xyz does not take effect in Slider. Mostly because the agent does not run with root privileges and cannot do an su. In general, Yarn has the model of running all processes as the yarn user when the cluster is non-secured and all processed run as the running user (kerberos principal) when the cluster is secured. On Thu, Nov 20, 2014 at 6:05 PM, hsy...@gmail.com hsy...@gmail.com wrote: Hi I specified user when call Execute(..., user='hdp',...) But the container processes are all launched as *yarn* user -- thanks Sumit
