[jira] [Resolved] (AURORA-1882) Add support for Mesos ContainerLaunchInfo

2017-03-13 Thread Santhosh Kumar Shanmugham (JIRA)

 [ 
https://issues.apache.org/jira/browse/AURORA-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Santhosh Kumar Shanmugham resolved AURORA-1882.
---
   Resolution: Fixed
 Assignee: Santhosh Kumar Shanmugham
Fix Version/s: 0.18.0

> Add support for Mesos ContainerLaunchInfo
> -
>
> Key: AURORA-1882
> URL: https://issues.apache.org/jira/browse/AURORA-1882
> Project: Aurora
>  Issue Type: Task
>  Components: Executor, Thermos
>Reporter: Santhosh Kumar Shanmugham
>Assignee: Santhosh Kumar Shanmugham
>Priority: Critical
> Fix For: 0.18.0
>
>
> Mesos-1.2.0 changes the interface for MesosContainerizer binary and drops 
> support for multiple switches. Without support for this Thermos Executor will 
> not be able to launch tasks successfully.
> {noformat}
> /usr/local/libexec/mesos/mesos-containerizer launch --help
> Usage: launch [options]
>   --[no-]help  Prints this help message (default: false)
>   --launch_info=VALUE
>   --namespace_mnt_target=VALUE The target 'pid' of the process whose 
> mount namespace we'd like
>to enter before executing the command.
>   --pipe_read=VALUEThe read end of the control pipe. This is 
> a file descriptor
>on Posix, or a handle on Windows. It's 
> caller's responsibility
>to make sure the file descriptor or the 
> handle is inherited
>properly in the subprocess. It's used to 
> synchronize with the
>parent process. If not specified, no 
> synchronization will happen.
>   --pipe_write=VALUE   The write end of the control pipe. This is 
> a file descriptor
>on Posix, or a handle on Windows. It's 
> caller's responsibility
>to make sure the file descriptor or the 
> handle is inherited
>properly in the subprocess. It's used to 
> synchronize with the
>parent process. If not specified, no 
> synchronization will happen.
>   --runtime_directory=VALUEThe runtime directory for the container 
> (used for checkpointing)
>   --[no-]unshare_namespace_mnt Whether to launch the command in a new 
> mount namespace. (default: false)
> {noformat}
> https://issues.apache.org/jira/browse/MESOS-6648



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (AURORA-1904) Support Mesos Maintenance

2017-03-13 Thread Zameer Manji (JIRA)
Zameer Manji created AURORA-1904:


 Summary: Support Mesos Maintenance
 Key: AURORA-1904
 URL: https://issues.apache.org/jira/browse/AURORA-1904
 Project: Aurora
  Issue Type: Task
Reporter: Zameer Manji
Priority: Minor


Support Mesos Maintenance primitives in Aurora per the design 
[doc|https://docs.google.com/document/d/1Z7dFAm6I1nrBE9S5WHw0D0LApBumkIbHrk0-ceoD2YI/edit#heading=h.n5tvzjaj9llx].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (AURORA-1904) Support Mesos Maintenance

2017-03-13 Thread Zameer Manji (JIRA)

 [ 
https://issues.apache.org/jira/browse/AURORA-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zameer Manji reassigned AURORA-1904:


Assignee: Zameer Manji

> Support Mesos Maintenance
> -
>
> Key: AURORA-1904
> URL: https://issues.apache.org/jira/browse/AURORA-1904
> Project: Aurora
>  Issue Type: Task
>Reporter: Zameer Manji
>Assignee: Zameer Manji
>Priority: Minor
>
> Support Mesos Maintenance primitives in Aurora per the design 
> [doc|https://docs.google.com/document/d/1Z7dFAm6I1nrBE9S5WHw0D0LApBumkIbHrk0-ceoD2YI/edit#heading=h.n5tvzjaj9llx].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (AURORA-1707) Remove deprecated resource fields in TaskConfig and ResourceAggregate

2017-03-13 Thread Stephan Erb (JIRA)

[ 
https://issues.apache.org/jira/browse/AURORA-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15922964#comment-15922964
 ] 

Stephan Erb commented on AURORA-1707:
-

Submitted patch towards the deprecation

{code}
commit 2f08d9110eb180968b2633523f1c2386874790e9
Author: Nicolás Donatucci 
Date:   Mon Mar 13 21:59:42 2017 +0100

Change Resource Validation in ConfigurationManager so that it validates the 
Resource Set instead of deprecated fields

The Resource validation in ConfigurationManager is now done against the 
Resource set instead of the NumCpus, RamMb and DiskMb fields.

Related Issue: AURORA-1707

Reviewed at https://reviews.apache.org/r/56395/

 
src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
 | 44 +---
 src/main/java/org/apache/aurora/scheduler/storage/log/ThriftBackfill.java  
   | 16 ++--
 src/main/python/apache/aurora/config/thrift.py 
   |  2 +-
 
src/test/java/org/apache/aurora/scheduler/configuration/ConfigurationManagerTest.java
 | 11 ---
 
src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
|  4 
 5 files changed, 28 insertions(+), 49 deletions(-)
{code}

> Remove deprecated resource fields in TaskConfig and ResourceAggregate
> -
>
> Key: AURORA-1707
> URL: https://issues.apache.org/jira/browse/AURORA-1707
> Project: Aurora
>  Issue Type: Task
>Reporter: Maxim Khutornenko
>Assignee: Nicolas Donatucci
>
> Remove individual resource fields in TaskConfig and ResourceAggregate 
> replaced by the new {{Resource}} struct.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Issue Comment Deleted] (AURORA-1871) Client should reject tasks with duplicate process names

2017-03-13 Thread Pradyumna Kaushik (JIRA)

 [ 
https://issues.apache.org/jira/browse/AURORA-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pradyumna Kaushik updated AURORA-1871:
--
Comment: was deleted

(was: [~joshua.cohen] Just a clarification -- Should the client just fail, in 
the sense that we throw an error indicating a faulty config file or should the 
job with tasks that contain duplicate task names be ignored and the others 
scheduled?)

> Client should reject tasks with duplicate process names
> ---
>
> Key: AURORA-1871
> URL: https://issues.apache.org/jira/browse/AURORA-1871
> Project: Aurora
>  Issue Type: Task
>  Components: Client
>Reporter: Joshua Cohen
>
> If a user creates a job that contains tasks with the same process name, that 
> info is happily passed on to thermos, which will happily run one of those 
> processes, but maybe display a separate one in the UI. In general the 
> behavior in this case is non-deterministic and can lead to hard to track down 
> bugs.
> We should just short circuit and fail in the client if we detect multiple 
> processes with the same name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)