[jira] [Comment Edited] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Kevin Klues (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212742#comment-15212742
 ] 

Kevin Klues edited comment on MESOS-3782 at 3/26/16 3:05 AM:
-

Yes. I was more curious about your actual plans for carrying out this specific 
change. That is, how do you envision adding duplicate binaries, creating 
symlinks, etc.


was (Author: klueska):
Yes. I was more curious about your actual plans for carrying out this specific 
change.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Kevin Klues (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212742#comment-15212742
 ] 

Kevin Klues commented on MESOS-3782:


Yes. I was more curious about your actual plans for carrying out this specific 
change.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Jay Guo (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212734#comment-15212734
 ] 

Jay Guo commented on MESOS-3782:


Long story short, the epic is to replace all keyword `slave` with `agent` in 
the project through several deprecation phase.

This ticket belongs to the epic here: 
https://issues.apache.org/jira/browse/MESOS-1478
And there's a design doc there. Please take a look.

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3782) Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create symlinks)

[Kevin Klues (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212714#comment-15212714
 ] 

Kevin Klues commented on MESOS-3782:


I'm curious what the actual plans for this work are. Could you elaborate in the 
description, please?

> Replace Master/Slave Terminology Phase I - Add duplicate binaries (or create 
> symlinks)
> --
>
> Key: MESOS-3782
> URL: https://issues.apache.org/jira/browse/MESOS-3782
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: zhou xing
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5023) MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.

[Gilbert Song (JIRA)]

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

Gilbert Song updated MESOS-5023:

Fix Version/s: 0.28.1

> MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.
> 
>
> Key: MESOS-5023
> URL: https://issues.apache.org/jira/browse/MESOS-5023
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Klaus Ma
>  Labels: mesosphere
> Fix For: 0.28.1
>
>
> Observed on the Apache Jenkins.
> {noformat}
> [ RUN  ] MesosContainerizerProvisionerTest.ProvisionFailed
> I0324 13:38:56.284261  2948 containerizer.cpp:666] Starting container 
> 'test_container' for executor 'executor' of framework ''
> I0324 13:38:56.285825  2939 containerizer.cpp:1421] Destroying container 
> 'test_container'
> I0324 13:38:56.285854  2939 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'test_container'
> [   OK ] MesosContainerizerProvisionerTest.ProvisionFailed (7 ms)
> [ RUN  ] MesosContainerizerProvisionerTest.DestroyWhileProvisioning
> I0324 13:38:56.291187  2944 containerizer.cpp:666] Starting container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2' for executor 'executor' of framework ''
> I0324 13:38:56.292157  2944 containerizer.cpp:1421] Destroying container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> I0324 13:38:56.292179  2944 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> F0324 13:38:56.292899  2944 containerizer.cpp:752] Check failed: 
> containers_.contains(containerId)
> *** Check failure stack trace: ***
> @ 0x2ac9973d0ae4  google::LogMessage::Fail()
> @ 0x2ac9973d0a30  google::LogMessage::SendToLog()
> @ 0x2ac9973d0432  google::LogMessage::Flush()
> @ 0x2ac9973d3346  google::LogMessageFatal::~LogMessageFatal()
> @ 0x2ac996af897c  
> mesos::internal::slave::MesosContainerizerProcess::_launch()
> @ 0x2ac996b1f18a  
> _ZZN7process8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS1_11ContainerIDERK6OptionINS1_8TaskInfoEERKNS1_12ExecutorInfoERKSsRKS8_ISsERKNS1_7SlaveIDERKNS_3PIDINS3_5SlaveEEEbRKS8_INS3_13ProvisionInfoEES5_SA_SD_SsSI_SL_SQ_bSU_EENS_6FutureIT_EERKNSO_IT0_EEMS10_FSZ_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_ENKUlPNS_11ProcessBaseEE_clES1P_
> @ 0x2ac996b479d9  
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS5_11ContainerIDERK6OptionINS5_8TaskInfoEERKNS5_12ExecutorInfoERKSsRKSC_ISsERKNS5_7SlaveIDERKNS0_3PIDINS7_5SlaveEEEbRKSC_INS7_13ProvisionInfoEES9_SE_SH_SsSM_SP_SU_bSY_EENS0_6FutureIT_EERKNSS_IT0_EEMS14_FS13_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x2ac997334fef  std::function<>::operator()()
> @ 0x2ac99731b1c7  process::ProcessBase::visit()
> @ 0x2ac997321154  process::DispatchEvent::visit()
> @   0x9a699c  process::ProcessBase::serve()
> @ 0x2ac9973173c0  process::ProcessManager::resume()
> @ 0x2ac99731445a  
> _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
> @ 0x2ac997320916  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
> @ 0x2ac9973208c6  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
> @ 0x2ac997320858  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
> @ 0x2ac9973207af  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
> @ 0x2ac997320748  
> _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
> @ 0x2ac9989aea60  (unknown)
> @ 0x2ac999125182  start_thread
> @ 0x2ac99943547d  (unknown)
> make[4]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[4]: *** [check-local] Aborted
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[2]: *** [check] Error 2
> make[2]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/mesos/mesos-0.29.0/_build'
> make: *** [distcheck] Error 1
> Build step 'Execute shell' marked build as failure
> {noformat}



--
This message was sent by Atlassian 

[jira] [Commented] (MESOS-2154) Port CFS quota support to Docker Containerizer

[Jie Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212580#comment-15212580
 ] 

Jie Yu commented on MESOS-2154:
---

commit 3927ba77a771acca3e38708a2b79e7556d2a3204
Author: Steve Niemitz 
Date:   Fri Mar 25 16:03:07 2016 -0700

Fix for docker containerizer not configuring CFS quotas correctly.

Note that this patch only handles the custom executor case. Command task
case is not handled yet due to some technical difficulty. Please see
details in comments of r33174.

It would be nice to refactor all this isolation code in a way that can
be shared between all containerizers, as this is basically just copied
from the CgroupsCpushareIsolator, but that's a much bigger undertaking.

Review: https://reviews.apache.org/r/33174/

> Port CFS quota support to Docker Containerizer
> --
>
> Key: MESOS-2154
> URL: https://issues.apache.org/jira/browse/MESOS-2154
> Project: Mesos
>  Issue Type: Improvement
>  Components: docker, isolation
>Affects Versions: 0.21.0
> Environment: Linux (Ubuntu 14.04.1)
>Reporter: Andrew Ortman
>Assignee: Steve Niemitz
>Priority: Minor
> Fix For: 0.29.0
>
>
> Port the CFS quota support the Mesos Containerizer has to the Docker 
> Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker 
> Containerizer should update the cfs_period_us and cfs_quota_us values to 
> allow hard CPU capping on the container. 
> Current workaround is to pass those values as LXC configuration parameters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-2154) Port CFS quota support to Docker Containerizer

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-2154:
--
Fix Version/s: 0.29.0

> Port CFS quota support to Docker Containerizer
> --
>
> Key: MESOS-2154
> URL: https://issues.apache.org/jira/browse/MESOS-2154
> Project: Mesos
>  Issue Type: Improvement
>  Components: docker, isolation
>Affects Versions: 0.21.0
> Environment: Linux (Ubuntu 14.04.1)
>Reporter: Andrew Ortman
>Assignee: Steve Niemitz
>Priority: Minor
> Fix For: 0.29.0
>
>
> Port the CFS quota support the Mesos Containerizer has to the Docker 
> Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker 
> Containerizer should update the cfs_period_us and cfs_quota_us values to 
> allow hard CPU capping on the container. 
> Current workaround is to pass those values as LXC configuration parameters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-2585) Use full width for mesos div.container

[Ian Babrou (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212576#comment-15212576
 ] 

Ian Babrou commented on MESOS-2585:
---

Have you guys tried it on regular screens? On my MBP: http://imgur.com/sX0FnLW

I'm afraid to imagine how it looks on production cluster where even current 
version can't fit numbers into the sidebar.

> Use full width for mesos div.container
> --
>
> Key: MESOS-2585
> URL: https://issues.apache.org/jira/browse/MESOS-2585
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Alson Kemp
>Assignee: Michael Lunøe
>Priority: Trivial
> Fix For: 0.28.0
>
> Attachments: After (patch 2).png, Narrow (current).png, Wide 
> (patched).png, github_full_width.png
>
>
> I've patched our Mesos installation so that the webui takes up the full page 
> width and is much nicer to look at on large monitors.  It's a small change.  
> If y'all want me to submit a PR with the update, I'll do so.
> Before:
> !https://issues.apache.org/jira/secure/attachment/12708818/Narrow%20%28current%29.png|width=800!
> After:
> !https://issues.apache.org/jira/secure/attachment/12708861/After%20%28patch%202%29.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5023) MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.

[Klaus Ma (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212573#comment-15212573
 ] 

Klaus Ma commented on MESOS-5023:
-

sure:)

> MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.
> 
>
> Key: MESOS-5023
> URL: https://issues.apache.org/jira/browse/MESOS-5023
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Klaus Ma
>  Labels: mesosphere
>
> Observed on the Apache Jenkins.
> {noformat}
> [ RUN  ] MesosContainerizerProvisionerTest.ProvisionFailed
> I0324 13:38:56.284261  2948 containerizer.cpp:666] Starting container 
> 'test_container' for executor 'executor' of framework ''
> I0324 13:38:56.285825  2939 containerizer.cpp:1421] Destroying container 
> 'test_container'
> I0324 13:38:56.285854  2939 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'test_container'
> [   OK ] MesosContainerizerProvisionerTest.ProvisionFailed (7 ms)
> [ RUN  ] MesosContainerizerProvisionerTest.DestroyWhileProvisioning
> I0324 13:38:56.291187  2944 containerizer.cpp:666] Starting container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2' for executor 'executor' of framework ''
> I0324 13:38:56.292157  2944 containerizer.cpp:1421] Destroying container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> I0324 13:38:56.292179  2944 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> F0324 13:38:56.292899  2944 containerizer.cpp:752] Check failed: 
> containers_.contains(containerId)
> *** Check failure stack trace: ***
> @ 0x2ac9973d0ae4  google::LogMessage::Fail()
> @ 0x2ac9973d0a30  google::LogMessage::SendToLog()
> @ 0x2ac9973d0432  google::LogMessage::Flush()
> @ 0x2ac9973d3346  google::LogMessageFatal::~LogMessageFatal()
> @ 0x2ac996af897c  
> mesos::internal::slave::MesosContainerizerProcess::_launch()
> @ 0x2ac996b1f18a  
> _ZZN7process8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS1_11ContainerIDERK6OptionINS1_8TaskInfoEERKNS1_12ExecutorInfoERKSsRKS8_ISsERKNS1_7SlaveIDERKNS_3PIDINS3_5SlaveEEEbRKS8_INS3_13ProvisionInfoEES5_SA_SD_SsSI_SL_SQ_bSU_EENS_6FutureIT_EERKNSO_IT0_EEMS10_FSZ_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_ENKUlPNS_11ProcessBaseEE_clES1P_
> @ 0x2ac996b479d9  
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS5_11ContainerIDERK6OptionINS5_8TaskInfoEERKNS5_12ExecutorInfoERKSsRKSC_ISsERKNS5_7SlaveIDERKNS0_3PIDINS7_5SlaveEEEbRKSC_INS7_13ProvisionInfoEES9_SE_SH_SsSM_SP_SU_bSY_EENS0_6FutureIT_EERKNSS_IT0_EEMS14_FS13_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x2ac997334fef  std::function<>::operator()()
> @ 0x2ac99731b1c7  process::ProcessBase::visit()
> @ 0x2ac997321154  process::DispatchEvent::visit()
> @   0x9a699c  process::ProcessBase::serve()
> @ 0x2ac9973173c0  process::ProcessManager::resume()
> @ 0x2ac99731445a  
> _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
> @ 0x2ac997320916  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
> @ 0x2ac9973208c6  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
> @ 0x2ac997320858  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
> @ 0x2ac9973207af  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
> @ 0x2ac997320748  
> _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
> @ 0x2ac9989aea60  (unknown)
> @ 0x2ac999125182  start_thread
> @ 0x2ac99943547d  (unknown)
> make[4]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[4]: *** [check-local] Aborted
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[2]: *** [check] Error 2
> make[2]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/mesos/mesos-0.29.0/_build'
> make: *** [distcheck] Error 1
> Build step 'Execute shell' marked build as failure
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4601) Don't dump stack trace on failure to bind()

[Yong Tang (JIRA)]

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

Yong Tang updated MESOS-4601:
-
Assignee: (was: Yong Tang)

> Don't dump stack trace on failure to bind()
> ---
>
> Key: MESOS-4601
> URL: https://issues.apache.org/jira/browse/MESOS-4601
> Project: Mesos
>  Issue Type: Bug
>  Components: libprocess
>Reporter: Neil Conway
>  Labels: errorhandling, libprocess, mesosphere, newbie
>
> We should do {{EXIT(EXIT_FAILURE)}} rather than {{LOG(FATAL)}}, both for this 
> code path and a few other expected error conditions in libprocess network 
> initialization.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5005) Make `ReservationInfo.principal` and `Persistence.principal` equivalent

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212531#comment-15212531
 ] 

Greg Mann commented on MESOS-5005:
--

IMO this should be addressed sooner rather than later. [~mcypark], 
[~adam-mesos], [~jieyu], [~jvanremoortere], any bandwidth to shepherd this? I'm 
on-call next sprint but this shouldn't be too complicated, might be a 
reasonable ticket for me to take on. [~hartem]

> Make `ReservationInfo.principal` and `Persistence.principal` equivalent
> ---
>
> Key: MESOS-5005
> URL: https://issues.apache.org/jira/browse/MESOS-5005
> Project: Mesos
>  Issue Type: Bug
>Reporter: Greg Mann
>  Labels: mesosphere, persistent-volumes, reservations
>
> Currently, we require that `ReservationInfo.principal` be equal to the 
> principal provided for authentication, which means that when HTTP 
> authentication is disabled this field cannot be set. Based on comments in 
> 'mesos.proto', the original intention was to enforce this same constraint for 
> `Persistence.principal`, but it seems that we don't enforce it. This should 
> be changed to make the two fields equivalent.
> This means that when HTTP authentication is disabled, requests to '/reserve' 
> cannot set {{ReservationInfo.principal}}, while requests to `/create-volumes` 
> can set any principal in {{Persistence.principal}}. One solution would be to 
> add the constraint to {{Persistence.principal}} when HTTP authentication is 
> enabled, and remove the constraint from {{ReservationInfo.principal}} when 
> HTTP authentication is disabled: this would allow us to track a 
> reserver/creator principal when HTTP authentication is disabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4760) Expose metrics and gauges for fetcher cache usage and hit rate

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212448#comment-15212448
 ] 

Vinod Kone commented on MESOS-4760:
---

Sorry I don't have cycles to shepherd :(

> Expose metrics and gauges for fetcher cache usage and hit rate
> --
>
> Key: MESOS-4760
> URL: https://issues.apache.org/jira/browse/MESOS-4760
> Project: Mesos
>  Issue Type: Improvement
>  Components: fetcher, statistics
>Reporter: Michael Browning
>Priority: Minor
>  Labels: features, fetcher, statistics
>
> To evaluate the fetcher cache and calibrate the value of the 
> fetcher_cache_size flag, it would be useful to have metrics and gauges on 
> agents that expose operational statistics like cache hit rate, occupied cache 
> size, and time spent downloading resources that were not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5035) Extend example persistent volume framework: reservations and lifetime

[Greg Mann (JIRA)]

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

Greg Mann updated MESOS-5035:
-
Description: 
The existing example persistent volume test framework would benefit from two 
improvements:
* It relies on statically reserved resources. To more accurately represent 
real-world use cases, and to remove the dependency on slaves with statically 
reserved resources, the framework should be updated to dynamically reserve the 
disk resources that it uses for persistent volumes.
* The framework currently runs quickly and then exits. It would be useful to 
have a command-line flag that allows the framework lifetime to be specified, so 
that it could run continuously for a specified length of time, or indefinitely. 
This would facilitate testing, including the testing of realistic live-upgrade 
scenarios.

  was:
The existing example persistent volume test framework would benefit from two 
improvements:
* It relies on statically reserved resources. To more accurately represent 
real-world use cases, and to remove a dependency of slaves with statically 
reserved resources, the framework should be updated to dynamically reserve the 
disk resources that it uses for persistent volumes.
* The framework currently runs quickly and then exits. It would be useful to 
have a command-line flag that allows the framework lifetime to be specified, so 
that it could run continuously for a specified length of time, or indefinitely. 
This would facilitate testing, including the testing of realistic live-upgrade 
scenarios.


> Extend example persistent volume framework: reservations and lifetime
> -
>
> Key: MESOS-5035
> URL: https://issues.apache.org/jira/browse/MESOS-5035
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Greg Mann
>  Labels: examples, mesosphere, persistent-volumes
>
> The existing example persistent volume test framework would benefit from two 
> improvements:
> * It relies on statically reserved resources. To more accurately represent 
> real-world use cases, and to remove the dependency on slaves with statically 
> reserved resources, the framework should be updated to dynamically reserve 
> the disk resources that it uses for persistent volumes.
> * The framework currently runs quickly and then exits. It would be useful to 
> have a command-line flag that allows the framework lifetime to be specified, 
> so that it could run continuously for a specified length of time, or 
> indefinitely. This would facilitate testing, including the testing of 
> realistic live-upgrade scenarios.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5023) MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.

[Gilbert Song (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212388#comment-15212388
 ] 

Gilbert Song commented on MESOS-5023:
-

The bug arises from `await()` in destroy(), which creates another future 
object. Thanks [~anandmazumdar] for investigating it together.

Hey [~klaus1982], sorry to ask that do you mind letting us to resolve this bug? 
Since it comes from a commit we merged two days ago, I should have it fixed 
asap. 

> MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.
> 
>
> Key: MESOS-5023
> URL: https://issues.apache.org/jira/browse/MESOS-5023
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Klaus Ma
>  Labels: mesosphere
>
> Observed on the Apache Jenkins.
> {noformat}
> [ RUN  ] MesosContainerizerProvisionerTest.ProvisionFailed
> I0324 13:38:56.284261  2948 containerizer.cpp:666] Starting container 
> 'test_container' for executor 'executor' of framework ''
> I0324 13:38:56.285825  2939 containerizer.cpp:1421] Destroying container 
> 'test_container'
> I0324 13:38:56.285854  2939 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'test_container'
> [   OK ] MesosContainerizerProvisionerTest.ProvisionFailed (7 ms)
> [ RUN  ] MesosContainerizerProvisionerTest.DestroyWhileProvisioning
> I0324 13:38:56.291187  2944 containerizer.cpp:666] Starting container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2' for executor 'executor' of framework ''
> I0324 13:38:56.292157  2944 containerizer.cpp:1421] Destroying container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> I0324 13:38:56.292179  2944 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> F0324 13:38:56.292899  2944 containerizer.cpp:752] Check failed: 
> containers_.contains(containerId)
> *** Check failure stack trace: ***
> @ 0x2ac9973d0ae4  google::LogMessage::Fail()
> @ 0x2ac9973d0a30  google::LogMessage::SendToLog()
> @ 0x2ac9973d0432  google::LogMessage::Flush()
> @ 0x2ac9973d3346  google::LogMessageFatal::~LogMessageFatal()
> @ 0x2ac996af897c  
> mesos::internal::slave::MesosContainerizerProcess::_launch()
> @ 0x2ac996b1f18a  
> _ZZN7process8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS1_11ContainerIDERK6OptionINS1_8TaskInfoEERKNS1_12ExecutorInfoERKSsRKS8_ISsERKNS1_7SlaveIDERKNS_3PIDINS3_5SlaveEEEbRKS8_INS3_13ProvisionInfoEES5_SA_SD_SsSI_SL_SQ_bSU_EENS_6FutureIT_EERKNSO_IT0_EEMS10_FSZ_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_ENKUlPNS_11ProcessBaseEE_clES1P_
> @ 0x2ac996b479d9  
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS5_11ContainerIDERK6OptionINS5_8TaskInfoEERKNS5_12ExecutorInfoERKSsRKSC_ISsERKNS5_7SlaveIDERKNS0_3PIDINS7_5SlaveEEEbRKSC_INS7_13ProvisionInfoEES9_SE_SH_SsSM_SP_SU_bSY_EENS0_6FutureIT_EERKNSS_IT0_EEMS14_FS13_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x2ac997334fef  std::function<>::operator()()
> @ 0x2ac99731b1c7  process::ProcessBase::visit()
> @ 0x2ac997321154  process::DispatchEvent::visit()
> @   0x9a699c  process::ProcessBase::serve()
> @ 0x2ac9973173c0  process::ProcessManager::resume()
> @ 0x2ac99731445a  
> _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
> @ 0x2ac997320916  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
> @ 0x2ac9973208c6  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
> @ 0x2ac997320858  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
> @ 0x2ac9973207af  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
> @ 0x2ac997320748  
> _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
> @ 0x2ac9989aea60  (unknown)
> @ 0x2ac999125182  start_thread
> @ 0x2ac99943547d  (unknown)
> make[4]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[4]: *** [check-local] Aborted
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory `/mesos/mesos-0.29.0/_build/src'
> make[2]: *** [check] Error 2
> make[2]: 

[jira] [Updated] (MESOS-3870) Prevent out-of-order libprocess message delivery

[Neil Conway (JIRA)]

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

Neil Conway updated MESOS-3870:
---
Epic Name: Ordered delivery in libprocess

> Prevent out-of-order libprocess message delivery
> 
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
>  Issue Type: Epic
>  Components: libprocess
>Reporter: Neil Conway
>Assignee: Neil Conway
>Priority: Minor
>  Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable 
> message delivery. So if P1 sends  to P2, P2 might see <>, , , 
> or  — but not .
> I suspect much of the code makes a similar assumption. However, it appears 
> that this behavior is not guaranteed. slave.cpp:2217 has the following 
> comment:
> {noformat}
>   // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
>   // ordered (i.e., slave receives them in the same order master sends
>   // them). This should be true in most of the cases because TCP
>   // enforces in order delivery per connection. However, the ordering
>   // is technically not guaranteed because master creates multiple
>   // connections to the slave in some cases (e.g., persistent socket
>   // to slave breaks and master uses ephemeral socket). This could
>   // potentially be solved by using a version number and rejecting
>   // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee 
> ordered message delivery, e.g., by adding a sequence number, or (2) 
> clarifying that ordered message delivery is not guaranteed, and ideally 
> providing a tool to force messages to be delivered out-of-order.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3870) Prevent out-of-order libprocess message delivery

[Neil Conway (JIRA)]

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

Neil Conway updated MESOS-3870:
---
Issue Type: Epic  (was: Bug)

> Prevent out-of-order libprocess message delivery
> 
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
>  Issue Type: Epic
>  Components: libprocess
>Reporter: Neil Conway
>Assignee: Neil Conway
>Priority: Minor
>  Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable 
> message delivery. So if P1 sends  to P2, P2 might see <>, , , 
> or  — but not .
> I suspect much of the code makes a similar assumption. However, it appears 
> that this behavior is not guaranteed. slave.cpp:2217 has the following 
> comment:
> {noformat}
>   // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
>   // ordered (i.e., slave receives them in the same order master sends
>   // them). This should be true in most of the cases because TCP
>   // enforces in order delivery per connection. However, the ordering
>   // is technically not guaranteed because master creates multiple
>   // connections to the slave in some cases (e.g., persistent socket
>   // to slave breaks and master uses ephemeral socket). This could
>   // potentially be solved by using a version number and rejecting
>   // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee 
> ordered message delivery, e.g., by adding a sequence number, or (2) 
> clarifying that ordered message delivery is not guaranteed, and ideally 
> providing a tool to force messages to be delivered out-of-order.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5031) Authorization Action enum does not support upgrades.

[Yong Tang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212336#comment-15212336
 ] 

Yong Tang commented on MESOS-5031:
--

Hi [~adam-mesos] I just added a review request:
https://reviews.apache.org/r/45342/
Let me know if there are any issues.

> Authorization Action enum does not support upgrades.
> 
>
> Key: MESOS-5031
> URL: https://issues.apache.org/jira/browse/MESOS-5031
> Project: Mesos
>  Issue Type: Bug
>Reporter: Adam B
>Assignee: Yong Tang
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We need to make the Action enum optional in authorization::Request, and add 
> an `UNKNOWN = 0;` enum value. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-5031) Authorization Action enum does not support upgrades.

[Yong Tang (JIRA)]

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

Yong Tang reassigned MESOS-5031:


Assignee: Yong Tang

> Authorization Action enum does not support upgrades.
> 
>
> Key: MESOS-5031
> URL: https://issues.apache.org/jira/browse/MESOS-5031
> Project: Mesos
>  Issue Type: Bug
>Reporter: Adam B
>Assignee: Yong Tang
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We need to make the Action enum optional in authorization::Request, and add 
> an `UNKNOWN = 0;` enum value. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5023) MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.

[Gilbert Song (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212275#comment-15212275
 ] 

Gilbert Song commented on MESOS-5023:
-

This failure comes from a race that the containers_[containerId] is erased 
accidentally. I am attaching the log which is the same flaky by comment out the 
check `CHECK(containers_.contains(containerId));` in _launch():

{noformat}
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from MesosContainerizerProvisionerTest
[ RUN  ] MesosContainerizerProvisionerTest.DestroyWhileProvisioning
I0325 19:01:02.686094 19729 containerizer.cpp:666] Starting container 
'63a1b3d5-dd19-453f-9953-439d4126c488' for executor 'executor' of framework ''
I0325 19:01:02.687070 19732 containerizer.cpp:1421] Destroying container 
'63a1b3d5-dd19-453f-9953-439d4126c488'
I0325 19:01:02.687110 19732 containerizer.cpp:1424] Waiting for the provisioner 
to complete for container '63a1b3d5-dd19-453f-9953-439d4126c488'
F0325 19:01:02.688181 19731 owned.hpp:110] Check failed: 'get()' Must be non 
NULL 
*** Check failure stack trace: ***
@ 0x7f00ae6fe84d  google::LogMessage::Fail()
@ 0x7f00ae6fdc2e  google::LogMessage::SendToLog()
@ 0x7f00ae6fe51d  google::LogMessage::Flush()
@ 0x7f00ae701968  google::LogMessageFatal::~LogMessageFatal()
@ 0x7f00adce4df4  google::CheckNotNull<>()
@ 0x7f00adc83760  process::Owned<>::operator->()
@ 0x7f00adc7154d  
mesos::internal::slave::MesosContainerizerProcess::_launch()
@ 0x7f00adcec610  
_ZZN7process8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS1_11ContainerIDERK6OptionINS1_8TaskInfoEERKNS1_12ExecutorInfoERKSsRKS8_ISsERKNS1_7SlaveIDERKNS_3PIDINS3_5SlaveEEEbRKS8_INS3_13ProvisionInfoEES5_SA_SD_SsSI_SL_SQ_bSU_EENS_6FutureIT_EERKNSO_IT0_EEMS10_FSZ_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_ENKUlPNS_11ProcessBaseEE_clES1P_
@ 0x7f00adcebf32  
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIbN5mesos8internal5slave25MesosContainerizerProcessERKNS5_11ContainerIDERK6OptionINS5_8TaskInfoEERKNS5_12ExecutorInfoERKSsRKSC_ISsERKNS5_7SlaveIDERKNS0_3PIDINS7_5SlaveEEEbRKSC_INS7_13ProvisionInfoEES9_SE_SH_SsSM_SP_SU_bSY_EENS0_6FutureIT_EERKNSS_IT0_EEMS14_FS13_T1_T2_T3_T4_T5_T6_T7_T8_T9_ET10_T11_T12_T13_T14_T15_T16_T17_T18_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
@ 0x7f00ae67c188  std::function<>::operator()()
@ 0x7f00ae666494  process::ProcessBase::visit()
@ 0x7f00ae6bdbde  process::DispatchEvent::visit()
@   0x857a71  process::ProcessBase::serve()
@ 0x7f00ae6641bd  process::ProcessManager::resume()
@ 0x7f00ae66c325  
process::ProcessManager::init_threads()::$_1::operator()()
@ 0x7f00ae66c263  
_ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvE3$_1St17reference_wrapperIKSt11atomic_boolEEE6__callIvJEJLm0T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
@ 0x7f00ae66c216  
_ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvE3$_1St17reference_wrapperIKSt11atomic_boolEEEclIJEvEET0_DpOT_
@ 0x7f00ae66c1c5  
_ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvE3$_1St17reference_wrapperIKSt11atomic_boolEEEvEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
@ 0x7f00ae66c195  std::_Bind_simple<>::operator()()
@ 0x7f00ae66c16c  std::thread::_Impl<>::_M_run()
@ 0x7f00a9742a60  (unknown)
@ 0x7f00a8f5f182  start_thread
@ 0x7f00a8c8c47d  (unknown)
{noformat}

> MesosContainerizerProvisionerTest.DestroyWhileProvisioning is flaky.
> 
>
> Key: MESOS-5023
> URL: https://issues.apache.org/jira/browse/MESOS-5023
> Project: Mesos
>  Issue Type: Bug
>Reporter: Alexander Rukletsov
>Assignee: Klaus Ma
>  Labels: mesosphere
>
> Observed on the Apache Jenkins.
> {noformat}
> [ RUN  ] MesosContainerizerProvisionerTest.ProvisionFailed
> I0324 13:38:56.284261  2948 containerizer.cpp:666] Starting container 
> 'test_container' for executor 'executor' of framework ''
> I0324 13:38:56.285825  2939 containerizer.cpp:1421] Destroying container 
> 'test_container'
> I0324 13:38:56.285854  2939 containerizer.cpp:1424] Waiting for the 
> provisioner to complete for container 'test_container'
> [   OK ] MesosContainerizerProvisionerTest.ProvisionFailed (7 ms)
> [ RUN  ] MesosContainerizerProvisionerTest.DestroyWhileProvisioning
> I0324 13:38:56.291187  2944 containerizer.cpp:666] Starting container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2' for executor 'executor' of framework ''
> I0324 13:38:56.292157  2944 containerizer.cpp:1421] Destroying container 
> 'c2316963-c6cb-4c7f-a3b9-17ca5931e5b2'
> I0324 13:38:56.292179  2944 

[jira] [Updated] (MESOS-5015) Call and Event Type enums in executor.proto should be optional

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-5015:
-
Labels: mesosphere  (was: )

> Call and Event Type enums in executor.proto should be optional
> --
>
> Key: MESOS-5015
> URL: https://issues.apache.org/jira/browse/MESOS-5015
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Vinod Kone
>Assignee: Yong Tang
>  Labels: mesosphere
>
> Having a 'required' Type enum has backwards compatibility issues when adding 
> new enum types. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4922) Setup proper /etc/hostname and /etc/hosts for containers in network/cni isolator.

[Artem Harutyunyan (JIRA)]

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

Artem Harutyunyan updated MESOS-4922:
-
Labels: mesosphere  (was: )

> Setup proper /etc/hostname and /etc/hosts for containers in network/cni 
> isolator.
> -
>
> Key: MESOS-4922
> URL: https://issues.apache.org/jira/browse/MESOS-4922
> Project: Mesos
>  Issue Type: Bug
>  Components: isolation
>Reporter: Qian Zhang
>Assignee: Qian Zhang
>  Labels: mesosphere
>
> The network/cni isolator needs to properly setup /etc/hostname and /etc/hosts 
> for the container with a hostname (e.g., randomly generated) and the assigned 
> IP returned by CNI plugin.
> We should consider the following cases:
> 1) container is using host filesystem
> 2) container is using a different filesystem
> 3) custom executor and command executor



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-4778) Add appc/runtime isolator for runtime isolation for appc images.

[Srinivas (JIRA)]

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

Srinivas reassigned MESOS-4778:
---

Assignee: Srinivas

> Add appc/runtime isolator for runtime isolation for appc images.
> 
>
> Key: MESOS-4778
> URL: https://issues.apache.org/jira/browse/MESOS-4778
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Srinivas
>
> Appc image also contains runtime information like 'exec', 'env', 
> 'workingDirectory' etc.
> https://github.com/appc/spec/blob/master/spec/aci.md
> Similar to docker images, we need to support a subset of them (mainly 'exec', 
> 'env' and 'workingDirectory').



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1739) Allow slave reconfiguration on restart

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212173#comment-15212173
 ] 

Vinod Kone commented on MESOS-1739:
---

Glad to hear you are interested in this. Unfortunately I do not have cycles to 
shepherd this.

> Allow slave reconfiguration on restart
> --
>
> Key: MESOS-1739
> URL: https://issues.apache.org/jira/browse/MESOS-1739
> Project: Mesos
>  Issue Type: Epic
>Reporter: Patrick Reilly
>  Labels: external-volumes, mesosphere, myriad
>
> Make it so that either via a slave restart or a out of process "reconfigure" 
> ping, the attributes and resources of a slave can be updated to be a superset 
> of what they used to be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3902) The Location header when non-leading master redirects to leading master is incomplete.

[Chris Lambert (JIRA)]

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

Chris Lambert updated MESOS-3902:
-
Labels: uber  (was: mesosphere)

> The Location header when non-leading master redirects to leading master is 
> incomplete.
> --
>
> Key: MESOS-3902
> URL: https://issues.apache.org/jira/browse/MESOS-3902
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API, master
>Affects Versions: 0.25.0
> Environment: 3 masters, 10 slaves
>Reporter: Ben Whitehead
>Assignee: Ashwin Murthy
>  Labels: uber
> Fix For: 0.29.0
>
>
> The master now sets a location header, but it's incomplete. The path of the 
> URL isn't set. Consider an example:
> {code}
> > cat /tmp/subscribe-1072944352375841456 | httpp POST 
> > 127.1.0.3:5050/api/v1/scheduler Content-Type:application/x-protobuf
> POST /api/v1/scheduler HTTP/1.1
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Content-Length: 123
> Content-Type: application/x-protobuf
> Host: 127.1.0.3:5050
> User-Agent: HTTPie/0.9.0
> +-+
> | NOTE: binary data not shown in terminal |
> +-+
> HTTP/1.1 307 Temporary Redirect
> Content-Length: 0
> Date: Fri, 26 Feb 2016 00:54:41 GMT
> Location: //127.1.0.1:5050
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5030) Expose TaskInfo's metadata to ResourceUsage struct

[Zhitao Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212162#comment-15212162
 ] 

Zhitao Li commented on MESOS-5030:
--

[~bmahler], my current plan for this task:
1. Add a `repeated TaskInfo task_infos` field to `ResourceUsage.Executor` 
protobuf message;
2. In implementation, task_infos will be a copy of all tasks associated with 
the same executor, with the following fields purged:
- data;
- executor_info (because it's already included once in the the enclosing 
protobuf).
3. In test, verify that ResourceUsage.Executor includes non-empty task_infos 
for a ResourceEstimator and QosController.

Please let me know whether the above plan sounds good.

> Expose TaskInfo's metadata to ResourceUsage struct
> --
>
> Key: MESOS-5030
> URL: https://issues.apache.org/jira/browse/MESOS-5030
> Project: Mesos
>  Issue Type: Improvement
>  Components: oversubscription
>Reporter: Zhitao Li
>Assignee: Zhitao Li
>  Labels: qos
>
> So QosController could use metadata information from TaskInfo.
> Based on conversations from Mesos work group, we would at least include:
> - task id;
> - name;
> - labels;
> ( I think resources, kill_policy should probably also included).
> Alternative would be just purge fields like `data`.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5029) Add labels to ExecutorInfo

[Zhitao Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212150#comment-15212150
 ] 

Zhitao Li commented on MESOS-5029:
--

[~bmahler], I think this task should be pretty straightforward:
1. I need to expand the `ExecutorInfo` protobuf in mesos.proto to include an 
`optional Labels labels` field;
2. Update CHANGELOG for API change;
3. Add a test case that a non-empty label is visible within the QosController 
in test.

Please comment if the above plan is right, then I'll start the patch.

> Add labels to ExecutorInfo
> --
>
> Key: MESOS-5029
> URL: https://issues.apache.org/jira/browse/MESOS-5029
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Zhitao Li
>Assignee: Zhitao Li
>Priority: Minor
>
> We want to to allow frameworks to populate metadata on ExecutorInfo object.
> An use case would be custom labels inspected by QosController.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5034) Design doc for ordered message delivery in libprocess

[Neil Conway (JIRA)]

Neil Conway created MESOS-5034:
--

 Summary: Design doc for ordered message delivery in libprocess
 Key: MESOS-5034
 URL: https://issues.apache.org/jira/browse/MESOS-5034
 Project: Mesos
  Issue Type: Task
  Components: libprocess
Reporter: Neil Conway
Assignee: Neil Conway






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5014) Call and Event Type enums in scheduler.proto should be optional

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-5014:
--
Labels: mesosphere  (was: )

> Call and Event Type enums in scheduler.proto should be optional
> ---
>
> Key: MESOS-5014
> URL: https://issues.apache.org/jira/browse/MESOS-5014
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Vinod Kone
>Assignee: Yong Tang
>  Labels: mesosphere
>
> Having a 'required' Type enum has backwards compatibility issues when adding 
> new enum types. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5028) Copy provisioner cannot replace directory with symlink

[Gilbert Song (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211971#comment-15211971
 ] 

Gilbert Song commented on MESOS-5028:
-

[~zhitao], thanks for investigating together. :)

Place a note here. The failure comes from cping a symlink to a directory. This 
situation is possible for some images. I would create a similar image tarball 
to test/fix it. 

> Copy provisioner cannot replace directory with symlink
> --
>
> Key: MESOS-5028
> URL: https://issues.apache.org/jira/browse/MESOS-5028
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Zhitao Li
>Assignee: Gilbert Song
>
> I'm trying to play with the new image provisioner on our custom docker 
> images, but one of layer failed to get copied, possibly due to a dangling 
> symlink.
> Error log with Glog_v=1:
> {quote}
> I0324 05:42:48.926678 15067 copy.cpp:127] Copying layer path 
> '/tmp/mesos/store/docker/layers/5df0888641196b88dcc1b97d04c74839f02a73b8a194a79e134426d6a8fcb0f1/rootfs'
>  to rootfs 
> '/var/lib/mesos/provisioner/containers/5f05be6c-c970-4539-aa64-fd0eef2ec7ae/backends/copy/rootfses/507173f3-e316-48a3-a96e-5fdea9ffe9f6'
> E0324 05:42:49.028506 15062 slave.cpp:3773] Container 
> '5f05be6c-c970-4539-aa64-fd0eef2ec7ae' for executor 'test' of framework 
> 75932a89-1514-4011-bafe-beb6a208bb2d-0004 failed to start: Collect failed: 
> Collect failed: Failed to copy layer: cp: cannot overwrite directory 
> ‘/var/lib/mesos/provisioner/containers/5f05be6c-c970-4539-aa64-fd0eef2ec7ae/backends/copy/rootfses/507173f3-e316-48a3-a96e-5fdea9ffe9f6/etc/apt’
>  with non-directory
> {quote}
> Content of 
> _/tmp/mesos/store/docker/layers/5df0888641196b88dcc1b97d04c74839f02a73b8a194a79e134426d6a8fcb0f1/rootfs/etc/apt_
>  points to a non-existing absolute path (cannot provide exact path but it's a 
> result of us trying to mount apt keys into docker container at build time).
> I believe what happened is that we executed a script at build time, which 
> contains equivalent of:
> {quote}
> rm -rf /etc/apt/* && ln -sf /build-mount-point/ /etc/apt
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5033) "Failed to shutdown socket" warning on OSX

[Neil Conway (JIRA)]

Neil Conway created MESOS-5033:
--

 Summary: "Failed to shutdown socket" warning on OSX
 Key: MESOS-5033
 URL: https://issues.apache.org/jira/browse/MESOS-5033
 Project: Mesos
  Issue Type: Bug
  Components: libprocess
Reporter: Neil Conway
Priority: Minor


{noformat}
E0325 11:50:49.198178 4820992 process.cpp:1962] Failed to shutdown socket with 
fd 10: Socket is not connected
{noformat}

The libprocess code for disconnecting an outbound socket appears to ~always 
emit this warning on OSX. Likely harmless but clutters up the logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros

[Yong Tang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211921#comment-15211921
 ] 

Yong Tang commented on MESOS-4112:
--

Hi [~mcypark],

Any chance to take a look at the review request
https://reviews.apache.org/r/45070/
or any suggestions on the lib process test macros overall?

Feedbacks are greatly appreciated.

> Clean up libprocess gtest macros
> 
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
>  Issue Type: Task
>  Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in 
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific 
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern 
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g. 
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their 
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over 
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}. 
> If this is the case, it would be worthwhile considering whether macros such 
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than 
> {{AWAIT_ASSERT_READY}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1739) Allow slave reconfiguration on restart

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211658#comment-15211658
 ] 

Deshi Xiao edited comment on MESOS-1739 at 3/25/16 10:48 AM:
-

[~vinodkone] i would like to working on it. firstly we need get the design docs 
done. i notice the http api propose is accepted, does it mean we support api 
trigger to change the configuration?

i have read your ideas on above comments, you like to propose:

1. Lets do the reconfiguration of a slave via a restart (at least for now) 
instead of via API endpoint.

in our requirement, we prefer API to update the attributes. another properties 
such as roles, i agree with your idea. so i suggest i can identify which config 
can use restart agent way, and else another config can use API to update. 




was (Author: xds2000):
[~vi...@twitter.com]  i would like to working on it. firstly we need get the 
design docs done. i notice the http api propose is accepted, does it mean we 
support api trigger to change the configuration?

i have read your ideas on above comments, you like to propose:

1. Lets do the reconfiguration of a slave via a restart (at least for now) 
instead of via API endpoint.

in our requirement, we prefer API to update the attributes. another properties 
such as roles, i agree with your idea. so i suggest i can identify which config 
can use restart agent way, and else another config can use API to update. 



> Allow slave reconfiguration on restart
> --
>
> Key: MESOS-1739
> URL: https://issues.apache.org/jira/browse/MESOS-1739
> Project: Mesos
>  Issue Type: Epic
>Reporter: Patrick Reilly
>  Labels: external-volumes, mesosphere, myriad
>
> Make it so that either via a slave restart or a out of process "reconfigure" 
> ping, the attributes and resources of a slave can be updated to be a superset 
> of what they used to be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1739) Allow slave reconfiguration on restart

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211658#comment-15211658
 ] 

Deshi Xiao commented on MESOS-1739:
---

[~vi...@twitter.com]  i would like to working on it. firstly we need get the 
design docs done. i notice the http api propose is accepted, does it mean we 
support api trigger to change the configuration?

i have read your ideas on above comments, you like to propose:

1. Lets do the reconfiguration of a slave via a restart (at least for now) 
instead of via API endpoint.

in our requirement, we prefer API to update the attributes. another properties 
such as roles, i agree with your idea. so i suggest i can identify which config 
can use restart agent way, and else another config can use API to update. 



> Allow slave reconfiguration on restart
> --
>
> Key: MESOS-1739
> URL: https://issues.apache.org/jira/browse/MESOS-1739
> Project: Mesos
>  Issue Type: Epic
>Reporter: Patrick Reilly
>  Labels: external-volumes, mesosphere, myriad
>
> Make it so that either via a slave restart or a out of process "reconfigure" 
> ping, the attributes and resources of a slave can be updated to be a superset 
> of what they used to be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211643#comment-15211643
 ] 

Deshi Xiao commented on MESOS-3059:
---

Adam, thanks for your remind. i will ask a shepherd to push the design. 

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Deshi Xiao (JIRA)]

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

Deshi Xiao updated MESOS-3059:
--
Assignee: (was: Deshi Xiao)

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211641#comment-15211641
 ] 

Deshi Xiao commented on MESOS-3059:
---

do we can scope the dynamically item, suppose here, we only dynamically assign 
roles or attributes to slaves. does it make sense? anyone can help shepherd it.

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>Assignee: Deshi Xiao
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211637#comment-15211637
 ] 

Adam B commented on MESOS-3059:
---

This is a non-trivial change, so please read the history in MESOS-1739 and 
related issues.
You'll also need a shepherd to help push the design/patches through, so please 
ask on the dev@ mailing list.

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>Assignee: Deshi Xiao
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Priority: Minor  (was: Major)

> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.29.0
>Reporter: Cody Maloney
>Priority: Minor
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Affects Version/s: (was: 0.21.1)
   0.29.0

> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.29.0
>Reporter: Cody Maloney
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Description: 
Currently two formats of credentials are supported: JSON

{code}
  "credentials": [
{
  "principal": "sherman",
  "secret": "kitesurf"
}
{code}

And a deprecated new line file:
{code}
principal1 secret1
pricipal2 secret2
{code}

We deprecated the new line format in 0.29, and should remove it after the 
deprecation cycle ends.

  was:
Currently two formats of credentials are supported: JSON

{code}
  "credentials": [
{
  "principal": "sherman",
  "secret": "kitesurf"
}
{code}

And a new line file:
{code}
principal1 secret1
pricipal2 secret2
{code}

We should deprecate the new line format and remove support for the old format.


> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>Assignee: Jan Schlicht
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Sprint:   (was: Mesosphere Sprint 31)

> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Fix Version/s: (was: 0.29.0)

> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

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

Adam B updated MESOS-5032:
--
Assignee: (was: Jan Schlicht)

> Remove plain text Credential format (after deprecation cycle)
> -
>
> Key: MESOS-5032
> URL: https://issues.apache.org/jira/browse/MESOS-5032
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>  Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
>   "credentials": [
> {
>   "principal": "sherman",
>   "secret": "kitesurf"
> }
> {code}
> And a deprecated new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We deprecated the new line format in 0.29, and should remove it after the 
> deprecation cycle ends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5032) Remove plain text Credential format (after deprecation cycle)

[Adam B (JIRA)]

Adam B created MESOS-5032:
-

 Summary: Remove plain text Credential format (after deprecation 
cycle)
 Key: MESOS-5032
 URL: https://issues.apache.org/jira/browse/MESOS-5032
 Project: Mesos
  Issue Type: Improvement
  Components: master, slave
Affects Versions: 0.21.1
Reporter: Cody Maloney
Assignee: Jan Schlicht
 Fix For: 0.29.0


Currently two formats of credentials are supported: JSON

{code}
  "credentials": [
{
  "principal": "sherman",
  "secret": "kitesurf"
}
{code}

And a new line file:
{code}
principal1 secret1
pricipal2 secret2
{code}

We should deprecate the new line format and remove support for the old format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211581#comment-15211581
 ] 

Deshi Xiao commented on MESOS-3059:
---

i will work on it

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>Assignee: Deshi Xiao
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-2154) Port CFS quota support to Docker Containerizer

[haosdent (JIRA)]

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

haosdent updated MESOS-2154:

Assignee: Steve Niemitz  (was: haosdent)

> Port CFS quota support to Docker Containerizer
> --
>
> Key: MESOS-2154
> URL: https://issues.apache.org/jira/browse/MESOS-2154
> Project: Mesos
>  Issue Type: Improvement
>  Components: docker, isolation
>Affects Versions: 0.21.0
> Environment: Linux (Ubuntu 14.04.1)
>Reporter: Andrew Ortman
>Assignee: Steve Niemitz
>Priority: Minor
>
> Port the CFS quota support the Mesos Containerizer has to the Docker 
> Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker 
> Containerizer should update the cfs_period_us and cfs_quota_us values to 
> allow hard CPU capping on the container. 
> Current workaround is to pass those values as LXC configuration parameters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes

[Deshi Xiao (JIRA)]

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

Deshi Xiao reassigned MESOS-3059:
-

Assignee: Deshi Xiao

> Allow http endpoint to dynamically change the slave attributes
> --
>
> Key: MESOS-3059
> URL: https://issues.apache.org/jira/browse/MESOS-3059
> Project: Mesos
>  Issue Type: Wish
>Reporter: Nitin
>Assignee: Deshi Xiao
>  Labels: mesosphere
>
> This is well understood that - changing the attributes dynamically is not 
> safe without a restart because slave itself may not know which old framework 
> tasks are running on it that were dependent on previous attributes. 
> However, total restart makes lot of other history to delete. We need to 
> ensure a dynamic attribute changes with a soft restart. 
> It will be good to expose a rest endpoint either at slave or mesos-master 
> which directly changes the state in zookeeper.
> USE-CASE
> We use slave attributes/roles to direct the framework scheduling to use 
> specific slave as per it's requirements. Mesos scheduler only creates the 
> offer on the basis of some resources.
> In our use case, we have some categorization of our spark frameworks or jobs 
> with framework(like marathon) based on multiple factors. We want job or 
> frameworks belonging to one category be running into their specific cluster 
> of resources. We want to dynamically manage the slaves into these logical 
> sub-clusters.
> Since number of jobs that will be submitted or when it will be submitted is 
> very dynamic, it make sense to be able to dynamically assign roles or 
> attributes to slaves. It is not possible to gauge the requirements at time of 
> cluster provisioning. Static role or attribute assignment leads to 
> sub-optimal use of the cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5031) Authorization Action enum does not support upgrades.

[Adam B (JIRA)]

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

Adam B updated MESOS-5031:
--
Fix Version/s: 0.29.0

> Authorization Action enum does not support upgrades.
> 
>
> Key: MESOS-5031
> URL: https://issues.apache.org/jira/browse/MESOS-5031
> Project: Mesos
>  Issue Type: Bug
>Reporter: Adam B
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We need to make the Action enum optional in authorization::Request, and add 
> an `UNKNOWN = 0;` enum value. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5031) Authorization Action enum does not support upgrades.

[Adam B (JIRA)]

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

Adam B updated MESOS-5031:
--
Labels: mesosphere security  (was: )

> Authorization Action enum does not support upgrades.
> 
>
> Key: MESOS-5031
> URL: https://issues.apache.org/jira/browse/MESOS-5031
> Project: Mesos
>  Issue Type: Bug
>Reporter: Adam B
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We need to make the Action enum optional in authorization::Request, and add 
> an `UNKNOWN = 0;` enum value. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5031) Authorization Action enum does not support upgrades.

[Adam B (JIRA)]

Adam B created MESOS-5031:
-

 Summary: Authorization Action enum does not support upgrades.
 Key: MESOS-5031
 URL: https://issues.apache.org/jira/browse/MESOS-5031
 Project: Mesos
  Issue Type: Bug
Reporter: Adam B


We need to make the Action enum optional in authorization::Request, and add an 
`UNKNOWN = 0;` enum value. See MESOS-4997 for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4580) Consider returning `202` (Accepted) for /reserve and related endpoints

[Jay Guo (JIRA)]

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

Jay Guo updated MESOS-4580:
---
Assignee: zhou xing  (was: Jay Guo)

> Consider returning `202` (Accepted) for /reserve and related endpoints
> --
>
> Key: MESOS-4580
> URL: https://issues.apache.org/jira/browse/MESOS-4580
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Neil Conway
>Assignee: zhou xing
>  Labels: mesosphere
>
> We currently return {{200}} (OK) when a POST to {{/reserve}}, {{/unreserve}}, 
> {{/create-volumes}}, and {{/destroy-volumes}} is validated successfully. This 
> is misleading, because the underlying operation is still dispatched 
> asynchronously and might subsequently fail. It would be more accurate to 
> return {{202}} (Accepted) instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)