[jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292791#comment-15292791 ] Guangya Liu commented on MESOS-5408: There are still document needs to be cleaned https://reviews.apache.org/r/47635/ > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > Fix For: 0.29.0 > > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3051) performance issues with port ranges comparison
[
https://issues.apache.org/jira/browse/MESOS-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292692#comment-15292692
]
Yanyan Hu commented on MESOS-3051:
--
Hi, guys, I'm now trying to use Mesos to manage a container cluster in large
scale. And I'm using Mesos-0.25.0 with Marathon stays upon it. But when I made
test using this environment, I found we still suffered from this issue when
Marathon allocated port resource randomly.
In my test, three Mesos-slaves were activated with each one has available port
resource of [31000-37000]. Then I tried to created more than 3000 tasks in
three slave nodes. I found when task amount reached 3000, it cost nearly 800
milisecond to finish a calculation of "Resources available =
slaves[slaveId].total - slaves[slaveId].allocated
" which is performed in HierarchicalAllocatorProcess::allocate() function:
https://github.com/apache/mesos/blob/0.25.0/src/master/allocator/mesos/hierarchical.hpp#L1284
Since I have three Mesos-slaves, the total time consumption of each invoking
for allocate() function is more than 2 seconds which make the performance of
Mesos-master very terrible.
So I tried to made a simple test to evaluate the performance of "Ranges" value
calculation. I found the performance of subtraction operation is still not good:
e.g. res1 = [1-6000], res2 = [1-1, 3-3, 5-5, ...]
I changed the range_size of res2 and recorded the execution time for "res1 -=
res", the result is as followed:
(Test was done in a x86 VM which has 4 process cores and 16GB memory)
res2 range_sizeexecution time(second)
10.003 (0.002 in kernel
mode)
1000.011
2000.031
4000.121
8000.533
1600 2.157
By comparison, the performance of addition and comparison operations are much
better. So looks like the current fix haven't completely resolved this problem.
Based on our test, the Mesos-master's performance seriously suffered from this
issue when task amount is more than 1 with 20 activated Mesos-slave nodes.
I haven't tried latest Mesos release, but after checking the code of
src/common/values.cpp in master branch, I found the implementation of "Ranges"
data type is almost the same as in 0.25.0 release:
https://github.com/apache/mesos/blob/master/src/common/values.cpp
https://github.com/apache/mesos/blob/0.25.0/src/common/values.cpp
So I guess the problem is still there? So is there any way we can further
optimize the implementation of "Ranges" data type so we can avoid this
performance bottleneck? Thanks.
> performance issues with port ranges comparison
> --
>
> Key: MESOS-3051
> URL: https://issues.apache.org/jira/browse/MESOS-3051
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Affects Versions: 0.22.1
>Reporter: James Peach
>Assignee: Joerg Schad
> Labels: mesosphere
> Fix For: 0.25.0, 0.24.2
>
>
> Testing in an environment with lots of frameworks (>200), where the
> frameworks permanently decline resources they don't need. The allocator ends
> up spending a lot of time figuring out whether offers are refused (the code
> path through {{HierarchicalAllocatorProcess::isFiltered()}}.
> In profiling a synthetic benchmark, it turns out that comparing port ranges
> is very expensive, involving many temporary allocations. 61% of
> Resources::contains() run time is in operator -= (Resource). 35% of
> Resources::contains() run time is in Resources::_contains().
> The heaviest call chain through {{Resources::_contains}} is:
> {code}
> Running Time Self (ms) Symbol Name
> 7237.0ms 35.5% 4.0
> mesos::Resources::_contains(mesos::Resource const&) const
> 7200.0ms 35.3% 1.0 mesos::contains(mesos::Resource
> const&, mesos::Resource const&)
> 7133.0ms 35.0%121.0
> mesos::operator<=(mesos::Value_Ranges const&, mesos::Value_Ranges const&)
> 6319.0ms 31.0% 7.0
> mesos::coalesce(mesos::Value_Ranges*, mesos::Value_Ranges const&)
> 6240.0ms 30.6%161.0
> mesos::coalesce(mesos::Value_Ranges*, mesos::Value_Range const&)
> 1867.0ms9.1% 25.0 mesos::Value_Ranges::add_range()
> 1694.0ms8.3% 4.0
> mesos::Value_Ranges::~Value_Ranges()
> 1495.0ms7.3% 16.0
> mesos::Value_Ranges::operator=(mesos::Value_Ranges const&)
> 445.0ms2.1% 94.0
> mesos::Value_Range::MergeFrom(mesos::Va
[jira] [Updated] (MESOS-1495) Create separate local data file to manage releases
[ https://issues.apache.org/jira/browse/MESOS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-1495: Attachment: website_pc.gif website_mobile.gif > Create separate local data file to manage releases > -- > > Key: MESOS-1495 > URL: https://issues.apache.org/jira/browse/MESOS-1495 > Project: Mesos > Issue Type: Bug > Components: project website >Reporter: Dave Lester >Assignee: haosdent > Attachments: website_mobile.gif, website_pc.gif > > > Currently, release info is managed in multiple places on the website. This > ticket is to create and manage a local data file which contains a release > number, link to release notes, and an optional blog post so that we can > dynamically display (incl adding and removing) releases from the website by > editing a single file. > Looks like we can achieve this with Middleman by creating a separate YAML > file: http://middlemanapp.com/advanced/local-data/, perhaps /releases.yml? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3639) Implement stout/os/windows/killtree.hpp
[ https://issues.apache.org/jira/browse/MESOS-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pravat updated MESOS-3639: - Description: killtree() is implemented using Windows Job Objects. The processes created by the executor are associated with a job object using `create_job'. killtree() is simply terminating the job object. Helper functions: `create_job` function creates a job object whose name is derived from the `pid` and associates the `pid` process with the job object. Every process started by the process which is part of the job object becomes part of the job object. The job name should match the name used in `kill_job`. The jobs should be create with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE and allow the caller to decide how to handle the returned handle. `kill_job` function assumes the process identified by `pid` is associated with a job object whose name is derive from it. Every process started by the process which is part of the job object becomes part of the job object. Destroying the task will close all such processes. was: killtree() is implemented using Windows Job Objects. The processes created by the executor are associated with a job object using `create_job'. killtree() is simply terminating the job object. Helper functions: `create_job` function creates a job object whose name is derived from the `pid` and associates the `pid` process with the job object. Every process started by the process which is part of the job object becomes part of the job object. The job name should match the name used in `kill_job`. `kill_job` function assumes the process identified by `pid` is associated with a job object whose name is derive from it. Every process started by the process which is part of the job object becomes part of the job object. Destroying the task will close all such processes. > Implement stout/os/windows/killtree.hpp > --- > > Key: MESOS-3639 > URL: https://issues.apache.org/jira/browse/MESOS-3639 > Project: Mesos > Issue Type: Task > Components: stout >Reporter: Alex Clemmer >Assignee: Daniel Pravat > Labels: mesosphere, windows > Fix For: 0.29.0 > > > killtree() is implemented using Windows Job Objects. The processes created by > the executor are associated with a job object using `create_job'. killtree() > is simply terminating the job object. > Helper functions: > `create_job` function creates a job object whose name is derived from the > `pid` and associates the `pid` process with the job object. Every process > started by the process which is part of the job object becomes part of the > job object. The job name should match the name used in `kill_job`. The jobs > should be create with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE and allow the caller > to decide how to handle the returned handle. > `kill_job` function assumes the process identified by `pid` is associated > with a job object whose name is derive from it. Every process started by the > process which is part of the job object becomes part of the job object. > Destroying the task will close all such processes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5301) Add synchronous validation for all types of Calls.
[
https://issues.apache.org/jira/browse/MESOS-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5301:
--
Description:
Currently, we do a best effort validation for all calls sent to the master from
the scheduler by invoking {{validation::scheduler::call::validate(call,
principal)}}. This is a generic validation helper for all calls. However, for
more fine grained validation for a particular call, we invoke the validation as
part of the call handle itself.
{code}
Option validationError = roles::validate(frameworkInfo.role());
{code}
This in turn makes all validations asynchronous i.e. the framework gets them as
{{Event::ERROR}} events later. It would be good if such validations can be
handled while processing the {{Call}} message itself synchronously.
was:
Currently, we do a best effort validation for all calls sent to the master from
the scheduler by invoking {{validation::scheduler::call::validate(call,
principal)}}. This is a generic validation helper for all calls. However, for
more coarse grained validation for a particular call, we invoke the validation
as part of the call handle itself.
{code}
Option validationError = roles::validate(frameworkInfo.role());
{code}
This in turn makes all validations asynchronous i.e. the framework gets them as
{{Event::ERROR}} events later. It would be good if such validations can be
handled while processing the {{Call}} message itself synchronously.
> Add synchronous validation for all types of Calls.
> --
>
> Key: MESOS-5301
> URL: https://issues.apache.org/jira/browse/MESOS-5301
> Project: Mesos
> Issue Type: Improvement
>Reporter: Anand Mazumdar
> Labels: mesosphere
>
> Currently, we do a best effort validation for all calls sent to the master
> from the scheduler by invoking {{validation::scheduler::call::validate(call,
> principal)}}. This is a generic validation helper for all calls. However, for
> more fine grained validation for a particular call, we invoke the validation
> as part of the call handle itself.
> {code}
> Option validationError = roles::validate(frameworkInfo.role());
> {code}
> This in turn makes all validations asynchronous i.e. the framework gets them
> as {{Event::ERROR}} events later. It would be good if such validations can be
> handled while processing the {{Call}} message itself synchronously.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5359) The scheduler library should have a delay before initiating a connection with master.
[ https://issues.apache.org/jira/browse/MESOS-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] José Guilherme Vanz reassigned MESOS-5359: -- Assignee: José Guilherme Vanz > The scheduler library should have a delay before initiating a connection with > master. > - > > Key: MESOS-5359 > URL: https://issues.apache.org/jira/browse/MESOS-5359 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.29.0 >Reporter: Anand Mazumdar >Assignee: José Guilherme Vanz > Labels: mesosphere > > Currently, the scheduler library does have an artificially induced delay when > trying to initially establish a connection with the master. In the event of a > master failover or ZK disconnect, a large number of frameworks can get > disconnected and then thereby overwhelm the master with TCP SYN requests. > On a large cluster with many agents, the master is already overwhelmed with > handling connection requests from the agents. This compounds the issue > further on the master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3777) Replace Master/Slave Terminology Phase I - Modify public interfaces
[ https://issues.apache.org/jira/browse/MESOS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] José Guilherme Vanz updated MESOS-3777: --- Assignee: (was: José Guilherme Vanz) > Replace Master/Slave Terminology Phase I - Modify public interfaces > > > Key: MESOS-3777 > URL: https://issues.apache.org/jira/browse/MESOS-3777 > Project: Mesos > Issue Type: Task >Reporter: Diana Arroyo > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2339) Mesos community pages should link the Modules mailing list.
[
https://issues.apache.org/jira/browse/MESOS-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292502#comment-15292502
]
haosdent commented on MESOS-2339:
-
I saw this have already been fixed. http://mesos.apache.org/community/
> Mesos community pages should link the Modules mailing list.
>
>
> Key: MESOS-2339
> URL: https://issues.apache.org/jira/browse/MESOS-2339
> Project: Mesos
> Issue Type: Improvement
> Components: project website
>Affects Versions: 0.20.1
>Reporter: Till Toenshoff
>
> http://mesos.apache.org/community/ should announce the Modules specific
> mailing list {{modu...@mesos.apache.org}} and how to subscribe to it:
> Mail to {{modules-subscr...@mesos.apache.org}} etc...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5278) Add a CLI allowing a user to enter a container.
[
https://issues.apache.org/jira/browse/MESOS-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292484#comment-15292484
]
Guangya Liu commented on MESOS-5278:
[~jieyu] , one question want to get some help from you:
1) The "mesos ps" can get all containers from the mesos cluster, so the
operator can run this command on any host in the mesos cluster.
2) for the new introduced CLI "mesos enter", as we need call {{setns}} to enter
the container and {{execvp}} to run the command in the container, seems this
command needs to be run on the agent where the container is running; otherwise,
we may need some logic to ssh to the agent where the container is running first.
Any comments?
[~idownes] what is the behaviour of your internal {{mesos enter}}? Thanks.
> Add a CLI allowing a user to enter a container.
> ---
>
> Key: MESOS-5278
> URL: https://issues.apache.org/jira/browse/MESOS-5278
> Project: Mesos
> Issue Type: Improvement
>Reporter: Jie Yu
>Assignee: Guangya Liu
>
> Containers created by the unified containerizer (Mesos containerizer) uses
> various namespaces (e.g., mount, network, etc.).
> To improve debugability, we should create a CLI that allows an operator or a
> user to enter the namespaces associated with the container, and execute an
> arbitrary command in that container (similar to `docker exec`).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5325) Mesos can't determine if task IP is reachable
[ https://issues.apache.org/jira/browse/MESOS-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292468#comment-15292468 ] Dan Osborne commented on MESOS-5325: Basically, Mesos *can* determine if an IP Address is routable, based on whether or not a network_info was provided in the task's definition. > Mesos can't determine if task IP is reachable > - > > Key: MESOS-5325 > URL: https://issues.apache.org/jira/browse/MESOS-5325 > Project: Mesos > Issue Type: Bug >Reporter: Dan Osborne > > I have uncovered a design flaw that affects ip-per-container tasks when run > in a cluster alongside non ip-per-container tasks. This affects > docker-libnetwork, netmodules, and I suspect it will also affect CNI. > After Mesos launches a docker bridge task, it fills the task's networkinfo > field with the docker bridge IP assigned to that task. Because of this > behavior, when a launched task's NetworkInfo is later utilized by Mesos > components, it is unknown if it is filled with an IP address accessible > throughout the cluster, or if it is not. > A common use case where this is a problem can be encountered when using Mesos > DNS. Mesos-DNS has a configuration setting that tells it which information to > respond to a query with: NetworkInfo, or HostIP. If it has been configured to > prefer NetworkInfo, it correctly resolves ip-per-container containers to > their unique IP. But, because the docker bridge IP is also stored in > NetworkInfo, it will incorrectly resolve docker-bridge containers to an IP > address not accessible from anywhere besides the slave they are on. This > breaks DNS resolutions in Mesos. > I believe Mesos needs a way to distinguish between tasks which are accessible > via their IP and tasks that are not. > One fix would be to prevent Mesos from filling in NetworkInfo for a task if > it is known that the task is not reachable throughout the cluster via that > address. Essentially, NetworkInfo could be interpreted as a boolean - Its > presence means this task is addressable. Its absence means the task is not. > In practice, this would mean it gets filled in for CNI tasks, netmodules > tasks, and docker tasks bound to the host networking namespace. It would not > get filled in for docker bridge tasks. > I believe this change would be fairly minimum in scope. To implement it, > Mesos would need to be changed to not store Docker Bridge IP's in NetworkInfo. > I'm also open to discussion and other suggestions on how to resolve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5325) Mesos can't determine if task IP is reachable
[ https://issues.apache.org/jira/browse/MESOS-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292465#comment-15292465 ] Dan Osborne commented on MESOS-5325: [~aavinash] I've had a think about this, and I don't believe your initial point is true. NetworkInfo is a repeated field in the ContainerInfo. By default, it will be an empty list. If it has at least one initialized NetworkInfo in it, this means the User/Framework has made a "Network Request", and therefore, the task should be reachable. https://github.com/apache/mesos/blob/0.27.0/include/mesos/mesos.proto#L1542 Therefore, we should not be extracting IP's and filling them in the NetworkInfo's IPAddress field if NetworkInfo was not initialized. Marathon, for example, already exhibits this behavior. If the ipAddress field is specified in Marathon, it flags that this is an ip-per-container task, so it will add a NetworkInfo to the repeated network_infos to request an IP Address. If the field is not specified, then Marathon leaves the network_infos as an empty list. In this case, its up to the user to not launch a Docker Bridge task using Marathon while also specifiying the ipAddress field. > Mesos can't determine if task IP is reachable > - > > Key: MESOS-5325 > URL: https://issues.apache.org/jira/browse/MESOS-5325 > Project: Mesos > Issue Type: Bug >Reporter: Dan Osborne > > I have uncovered a design flaw that affects ip-per-container tasks when run > in a cluster alongside non ip-per-container tasks. This affects > docker-libnetwork, netmodules, and I suspect it will also affect CNI. > After Mesos launches a docker bridge task, it fills the task's networkinfo > field with the docker bridge IP assigned to that task. Because of this > behavior, when a launched task's NetworkInfo is later utilized by Mesos > components, it is unknown if it is filled with an IP address accessible > throughout the cluster, or if it is not. > A common use case where this is a problem can be encountered when using Mesos > DNS. Mesos-DNS has a configuration setting that tells it which information to > respond to a query with: NetworkInfo, or HostIP. If it has been configured to > prefer NetworkInfo, it correctly resolves ip-per-container containers to > their unique IP. But, because the docker bridge IP is also stored in > NetworkInfo, it will incorrectly resolve docker-bridge containers to an IP > address not accessible from anywhere besides the slave they are on. This > breaks DNS resolutions in Mesos. > I believe Mesos needs a way to distinguish between tasks which are accessible > via their IP and tasks that are not. > One fix would be to prevent Mesos from filling in NetworkInfo for a task if > it is known that the task is not reachable throughout the cluster via that > address. Essentially, NetworkInfo could be interpreted as a boolean - Its > presence means this task is addressable. Its absence means the task is not. > In practice, this would mean it gets filled in for CNI tasks, netmodules > tasks, and docker tasks bound to the host networking namespace. It would not > get filled in for docker bridge tasks. > I believe this change would be fairly minimum in scope. To implement it, > Mesos would need to be changed to not store Docker Bridge IP's in NetworkInfo. > I'm also open to discussion and other suggestions on how to resolve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5420) Implement os::exists for processes
Daniel Pravat created MESOS-5420: Summary: Implement os::exists for processes Key: MESOS-5420 URL: https://issues.apache.org/jira/browse/MESOS-5420 Project: Mesos Issue Type: Improvement Environment: Windows Reporter: Daniel Pravat Assignee: Daniel Pravat os::exists returns true if the process identified by the parameter is still running or was running. In Windows, subprocess class keeps an open handle to the process, allowing ReaperProcess::reap to get the exit code even if the process is terminated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5419) Document all known client libraries for the Scheduler/Executor API
Anand Mazumdar created MESOS-5419: - Summary: Document all known client libraries for the Scheduler/Executor API Key: MESOS-5419 URL: https://issues.apache.org/jira/browse/MESOS-5419 Project: Mesos Issue Type: Documentation Reporter: Anand Mazumdar Previously during various community syncs, we had decided that we would only be supporting the C++ scheduler/executor library in the Mesos code base going forward. We should however, still document the client libraries available in various languages to drive adoption/have a recommended list for users to look up. This can be similar to the already existing frameworks doc: http://mesos.apache.org/documentation/latest/frameworks/ Other projects also seem to have been following a similar practice: https://docs.docker.com/engine/reference/api/remote_api_client_libraries/ https://github.com/kubernetes/kubernetes/blob/master/docs/devel/client-libraries.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5418) Test case: Escape containerizer command line on Windows
[
https://issues.apache.org/jira/browse/MESOS-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Pravat updated MESOS-5418:
-
Priority: Minor (was: Major)
Issue Type: Task (was: Improvement)
Summary: Test case: Escape containerizer command line on Windows (was:
Escape containerizer command line on Windows)
> Test case: Escape containerizer command line on Windows
> ---
>
> Key: MESOS-5418
> URL: https://issues.apache.org/jira/browse/MESOS-5418
> Project: Mesos
> Issue Type: Task
> Environment: Windows
>Reporter: Daniel Pravat
>Priority: Minor
>
> The json command sent to the containerizer is malformed if the double quotes
> characters are not escaped on Windows. The code should be extracted in a
> separate function and a test case should be added.
> Tha command line show be similar to the following:
>CmdLine: mesos-containerizer.exe launch
> --command={\"environment\":{\"variables\":[{\"name\":\"MARATHON_APP_VERSION\",\"value\":\"2016-05-17T19:01:41.164Z\"}
> ,{\"name\":\"HOST\",\"value\":\"10.6.0.4\"},{\"name\":\"MARATHON_APP_RESOURCE_CPUS\",\"value\":\"0.1\"},{\"name\":\"PORT_10001\",\"value\":\"31090\"},{\"name\":
> \"MESOS_TASK_ID\",\"value\":\"2.b1ab4785-1e14-11e6-8677-000d3a3000b0\"},{\"name\":\"PORT\",\"value\":\"31090\"},{\"name\":\"MARATHON_APP_RESOURCE_MEM\",\"value\
> ":\"128.0\"},{\"name\":\"PORTS\",\"value\":\"31090\"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5418) Escape containerizer command line on Windows
Daniel Pravat created MESOS-5418:
Summary: Escape containerizer command line on Windows
Key: MESOS-5418
URL: https://issues.apache.org/jira/browse/MESOS-5418
Project: Mesos
Issue Type: Improvement
Environment: Windows
Reporter: Daniel Pravat
The json command sent to the containerizer is malformed if the double quotes
characters are not escaped on Windows. The code should be extracted in a
separate function and a test case should be added.
Tha command line show be similar to the following:
CmdLine: mesos-containerizer.exe launch
--command={\"environment\":{\"variables\":[{\"name\":\"MARATHON_APP_VERSION\",\"value\":\"2016-05-17T19:01:41.164Z\"}
,{\"name\":\"HOST\",\"value\":\"10.6.0.4\"},{\"name\":\"MARATHON_APP_RESOURCE_CPUS\",\"value\":\"0.1\"},{\"name\":\"PORT_10001\",\"value\":\"31090\"},{\"name\":
\"MESOS_TASK_ID\",\"value\":\"2.b1ab4785-1e14-11e6-8677-000d3a3000b0\"},{\"name\":\"PORT\",\"value\":\"31090\"},{\"name\":\"MARATHON_APP_RESOURCE_MEM\",\"value\
":\"128.0\"},{\"name\":\"PORTS\",\"value\":\"31090\"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5416) make check of stout fails.
[
https://issues.apache.org/jira/browse/MESOS-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-5416:
---
Assignee: haosdent
> make check of stout fails.
> --
>
> Key: MESOS-5416
> URL: https://issues.apache.org/jira/browse/MESOS-5416
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: haosdent
>
> When trying to build stout's tests on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/stout
> $ bootstrap
> $ mkdir build
> $ cd build/
> $ ../configure
> $ make check
> [...]
> ../tests/bytes_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:766: recipe for target 'stout_tests-bytes_tests.o' failed
> make[2]: *** [stout_tests-bytes_tests.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> ../tests/base64_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> ../tests/bits_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:738: recipe for target 'stout_tests-base64_tests.o' failed
> make[2]: *** [stout_tests-base64_tests.o] Error 1
> ../tests/duration_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file
> or directory
> compilation terminated.
> Makefile:752: recipe for target 'stout_tests-bits_tests.o' failed
> make[2]: *** [stout_tests-bits_tests.o] Error 1
> Makefile:794: recipe for target 'stout_tests-duration_tests.o' failed
> make[2]: *** [stout_tests-duration_tests.o] Error 1
> ../tests/adaptor_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:724: recipe for target 'stout_tests-adaptor_tests.o' failed
> make[2]: *** [stout_tests-adaptor_tests.o] Error 1
> ../tests/cache_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:780: recipe for target 'stout_tests-cache_tests.o' failed
> make[2]: *** [stout_tests-cache_tests.o] Error 1
> make[2]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
> Makefile:1706: recipe for target 'check-am' failed
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
> Makefile:1418: recipe for target 'check-recursive' failed
> make: *** [check-recursive] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5415) bootstrap of libprocess fails.
[
https://issues.apache.org/jira/browse/MESOS-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-5415:
---
Assignee: haosdent
> bootstrap of libprocess fails.
> --
>
> Key: MESOS-5415
> URL: https://issues.apache.org/jira/browse/MESOS-5415
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: haosdent
>
> When trying to build libprocess on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/libprocess
> $ ./bootstrap
> […]
> configure.ac:64: error: required file '3rdparty/gmock_sources.cc.in' not found
> {noformat}
> So the standalone {{configure.ac}} still tries to locate
> {{gmock_source.cc.in}} in a subfolder called {{3rdparty}} while it should
> actually try to locate it in its parent folder.
> {noformat}
> $ ll /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> -rw-rw-r--. 1 till till 730 May 19 13:22
> /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5417) define WSTRINGIFY behaviour on Windows
[ https://issues.apache.org/jira/browse/MESOS-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pravat updated MESOS-5417: - Shepherd: Joris Van Remoortere > define WSTRINGIFY behaviour on Windows > -- > > Key: MESOS-5417 > URL: https://issues.apache.org/jira/browse/MESOS-5417 > Project: Mesos > Issue Type: Improvement >Reporter: Daniel Pravat >Assignee: Daniel Pravat >Priority: Minor > Labels: windows > > Identify the proper behaviour of WSTRINGIFY to improve the logging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5417) define WSTRINGIFY behaviour on Windows
[ https://issues.apache.org/jira/browse/MESOS-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pravat updated MESOS-5417: - Labels: windows (was: ) > define WSTRINGIFY behaviour on Windows > -- > > Key: MESOS-5417 > URL: https://issues.apache.org/jira/browse/MESOS-5417 > Project: Mesos > Issue Type: Improvement >Reporter: Daniel Pravat >Assignee: Daniel Pravat >Priority: Minor > Labels: windows > > Identify the proper behaviour of WSTRINGIFY to improve the logging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5417) define WSTRINGIFY behaviour on Windows
Daniel Pravat created MESOS-5417: Summary: define WSTRINGIFY behaviour on Windows Key: MESOS-5417 URL: https://issues.apache.org/jira/browse/MESOS-5417 Project: Mesos Issue Type: Improvement Reporter: Daniel Pravat Assignee: Daniel Pravat Priority: Minor Identify the proper behaviour of WSTRINGIFY to improve the logging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5362) Add authentication to example frameworks
[ https://issues.apache.org/jira/browse/MESOS-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann reassigned MESOS-5362: Assignee: Greg Mann > Add authentication to example frameworks > > > Key: MESOS-5362 > URL: https://issues.apache.org/jira/browse/MESOS-5362 > Project: Mesos > Issue Type: Improvement > Components: security >Reporter: Greg Mann >Assignee: Greg Mann > Labels: authentication, mesosphere, security > > Some example frameworks do not have the ability to authenticate with the > master. Adding authentication to the example frameworks that don't already > have it implemented would allow us to use these frameworks for testing in > authenticated/authorized scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5215) Update the documentation for '/reserve' and '/create-volumes'
[
https://issues.apache.org/jira/browse/MESOS-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-5215:
-
Shepherd: Bernd Mathiske
Sprint: Mesosphere Sprint 35
> Update the documentation for '/reserve' and '/create-volumes'
> -
>
> Key: MESOS-5215
> URL: https://issues.apache.org/jira/browse/MESOS-5215
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Affects Versions: 0.28.1
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: documentation, mesosphere
> Fix For: 0.29.0
>
>
> There are a couple issues related to the {{principal}} field in {{DiskInfo}}
> and {{ReservationInfo}} (see linked JIRAs) that should be better documented.
> We need to help users understand the purpose of these fields and how they
> interact with the principal provided in the HTTP authentication header. See
> linked tickets for background.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5060) Requesting /files/read.json with a negative length value causes subsequent /files requests to 404.
[ https://issues.apache.org/jira/browse/MESOS-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292091#comment-15292091 ] Greg Mann commented on MESOS-5060: -- [~dongdong], great thanks! I tested the patch in the webui, and the pailer is functioning correctly. [~bmahler], could you take a look at the patch when you have a chance? > Requesting /files/read.json with a negative length value causes subsequent > /files requests to 404. > -- > > Key: MESOS-5060 > URL: https://issues.apache.org/jira/browse/MESOS-5060 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 > Environment: Mesos 0.23.0 on CentOS 6, also Mesos 0.28.0 on OSX >Reporter: Tom Petr >Assignee: zhou xing >Priority: Minor > Fix For: 0.29.0 > > > I accidentally hit a slave's /files/read.json endpoint with a negative length > (ex. http://hostname:5051/files/read.json?path=XXX&offset=0&length=-100). The > HTTP request timed out after 30 seconds with nothing relevant in the slave > logs, and subsequent calls to any of the /files endpoints on that slave > immediately returned a HTTP 404 response. We ultimately got things working > again by restarting the mesos-slave process (checkpointing FTW!), but it'd be > wise to guard against negative lengths on the slave's end too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5416) make check of stout fails.
Till Toenshoff created MESOS-5416:
-
Summary: make check of stout fails.
Key: MESOS-5416
URL: https://issues.apache.org/jira/browse/MESOS-5416
Project: Mesos
Issue Type: Bug
Affects Versions: 0.29.0
Reporter: Till Toenshoff
When trying to build stout's tests on its own, I am hitting the following:
{noformat}
$ pwd
/home/till/scratchpad/mesos/3rdparty/stout
$ bootstrap
$ mkdir build
$ cd build/
$ ../configure
$ make check
[...]
../tests/bytes_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
Makefile:766: recipe for target 'stout_tests-bytes_tests.o' failed
make[2]: *** [stout_tests-bytes_tests.o] Error 1
make[2]: *** Waiting for unfinished jobs
../tests/base64_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
../tests/bits_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
Makefile:738: recipe for target 'stout_tests-base64_tests.o' failed
make[2]: *** [stout_tests-base64_tests.o] Error 1
../tests/duration_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
Makefile:752: recipe for target 'stout_tests-bits_tests.o' failed
make[2]: *** [stout_tests-bits_tests.o] Error 1
Makefile:794: recipe for target 'stout_tests-duration_tests.o' failed
make[2]: *** [stout_tests-duration_tests.o] Error 1
../tests/adaptor_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
Makefile:724: recipe for target 'stout_tests-adaptor_tests.o' failed
make[2]: *** [stout_tests-adaptor_tests.o] Error 1
../tests/cache_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
directory
compilation terminated.
Makefile:780: recipe for target 'stout_tests-cache_tests.o' failed
make[2]: *** [stout_tests-cache_tests.o] Error 1
make[2]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
Makefile:1706: recipe for target 'check-am' failed
make[1]: *** [check-am] Error 2
make[1]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
Makefile:1418: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5415) bootstrap of libprocess fails.
Till Toenshoff created MESOS-5415:
-
Summary: bootstrap of libprocess fails.
Key: MESOS-5415
URL: https://issues.apache.org/jira/browse/MESOS-5415
Project: Mesos
Issue Type: Bug
Affects Versions: 0.29.0
Reporter: Till Toenshoff
When trying to build libprocess on its own, I am hitting the following:
{noformat}
$ pwd
/home/till/scratchpad/mesos/3rdparty/libprocess
$ ./bootstrap
[…]
configure.ac:64: error: required file '3rdparty/gmock_sources.cc.in' not found
{noformat}
So the standalone {{configure.ac}} still tries to locate {{gmock_source.cc.in}}
in a subfolder called {{3rdparty}} while it should actually try to locate it in
its parent folder.
{noformat}
$ ll /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
-rw-rw-r--. 1 till till 730 May 19 13:22
/home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4135) Labels are not return in statusUpdate TaskStatus
[ https://issues.apache.org/jira/browse/MESOS-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291692#comment-15291692 ] Srinivas commented on MESOS-4135: - Hi, I need shepherd to understand the issue fully. But I do have a solution, https://reviews.apache.org/r/47608/ Please let me know your comments. > Labels are not return in statusUpdate TaskStatus > > > Key: MESOS-4135 > URL: https://issues.apache.org/jira/browse/MESOS-4135 > Project: Mesos > Issue Type: Bug > Components: framework, master >Affects Versions: 0.25.0 >Reporter: Felix Hupfeld >Assignee: Srinivas >Priority: Minor > > Labels that were set in the task's TaskInfo upon creation are not returned in > statusUpdate TaskStatus messages. > This restricts their usefulness. Use case would be maintaining the container > version of a running task. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291666#comment-15291666
]
Kevin Klues commented on MESOS-5414:
Two more follow on patches:
https://reviews.apache.org/r/47609/
https://reviews.apache.org/r/47610/
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Kevin Klues
>Priority: Blocker
> Fix For: 0.29.0
>
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5395) Task getting stuck in staging state if launch it on a rebooted slave.
[
https://issues.apache.org/jira/browse/MESOS-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291648#comment-15291648
]
Joseph Wu commented on MESOS-5395:
--
Nothing in the mesos logs indicates that your task is *not* starting:
>From the stdout file, the task you're looking at is
{code}
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e
{code}
The agent logs say that the task started successfully. These timestamps lines
up very closely with the task's stderr.
{code}
I0518 14:55:19.393923 947 slave.cpp:1361] Got assigned task
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e for
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
I0518 14:55:19.394619 947 gc.cpp:83] Unscheduling
'/var/mesos/slaves/282745ab-423a-4350-a449-3e8cdfccfb93-S2/frameworks/17cd3756-1d59-4dfc-984d-3fe09f6b5730-'
from gc
I0518 14:55:19.394680 947 gc.cpp:83] Unscheduling
'/var/mesos/meta/slaves/282745ab-423a-4350-a449-3e8cdfccfb93-S2/frameworks/17cd3756-1d59-4dfc-984d-3fe09f6b5730-'
from gc
I0518 14:55:19.394760 947 slave.cpp:1480] Launching task
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e for
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
I0518 14:55:19.395539 947 paths.cpp:528] Trying to chown
'/var/mesos/slaves/282745ab-423a-4350-a449-3e8cdfccfb93-S2/frameworks/17cd3756-1d59-4dfc-984d-3fe09f6b5730-/executors/project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e/runs/d3996d05-26f6-4e6c-a89f-8ee9c617182c'
to user 'root'
I0518 14:55:19.399237 947 slave.cpp:5367] Launching executor
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- with resources cpus(*):0.1;
mem(*):32 in work directory
'/var/mesos/slaves/282745ab-423a-4350-a449-3e8cdfccfb93-S2/frameworks/17cd3756-1d59-4dfc-984d-3fe09f6b5730-/executors/project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e/runs/d3996d05-26f6-4e6c-a89f-8ee9c617182c'
I0518 14:55:19.399588 947 slave.cpp:1698] Queuing task
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' for
executor
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
I0518 14:55:19.402344 948 docker.cpp:1036] Starting container
'd3996d05-26f6-4e6c-a89f-8ee9c617182c' for task
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' (and
executor
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e') of
framework '17cd3756-1d59-4dfc-984d-3fe09f6b5730-'
...
I0518 14:55:26.880151 952 docker.cpp:623] Checkpointing pid 6331 to
'/var/mesos/meta/slaves/282745ab-423a-4350-a449-3e8cdfccfb93-S2/frameworks/17cd3756-1d59-4dfc-984d-3fe09f6b5730-/executors/project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e/runs/d3996d05-26f6-4e6c-a89f-8ee9c617182c/pids/forked.pid'
I0518 14:55:26.907119 952 slave.cpp:2643] Got registration for executor
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- from
executor(1)@10.254.234.236:42289
I0518 14:55:26.907639 952 docker.cpp:1316] Ignoring updating container
'd3996d05-26f6-4e6c-a89f-8ee9c617182c' with resources passed to update is
identical to existing resources
I0518 14:55:26.907726 952 slave.cpp:1863] Sending queued task
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' to
executor
'project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e' of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- at
executor(1)@10.254.234.236:42289
I0518 14:55:27.622561 952 slave.cpp:3002] Handling status update TASK_RUNNING
(UUID: 26e73671-099c-49f1-a031-57aa9a8cec41) for task
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- from
executor(1)@10.254.234.236:42289
I0518 14:55:27.622762 953 status_update_manager.cpp:320] Received status
update TASK_RUNNING (UUID: 26e73671-099c-49f1-a031-57aa9a8cec41) for task
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
I0518 14:55:27.622974 953 status_update_manager.cpp:824] Checkpointing UPDATE
for status update TASK_RUNNING (UUID: 26e73671-099c-49f1-a031-57aa9a8cec41) for
task project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730-
I0518 14:55:27.679003 953 slave.cpp:3400] Forwarding the update TASK_RUNNING
(UUID: 26e73671-099c-49f1-a031-57aa9a8cec41) for task
project-hub_project-hub-frontend.64b60262-1cef-11e6-bb25-d00d2cce797e of
framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- to
master@10.254.226.211:5050
I0518 14:55:27.679095 953 slave.cpp:3310] Sending
[jira] [Commented] (MESOS-4135) Labels are not return in statusUpdate TaskStatus
[ https://issues.apache.org/jira/browse/MESOS-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291639#comment-15291639 ] Ondřej Smola commented on MESOS-4135: - Hi, same for me - would really help us implement out use case in much more straightfoward way. > Labels are not return in statusUpdate TaskStatus > > > Key: MESOS-4135 > URL: https://issues.apache.org/jira/browse/MESOS-4135 > Project: Mesos > Issue Type: Bug > Components: framework, master >Affects Versions: 0.25.0 >Reporter: Felix Hupfeld >Assignee: Srinivas >Priority: Minor > > Labels that were set in the task's TaskInfo upon creation are not returned in > statusUpdate TaskStatus messages. > This restricts their usefulness. Use case would be maintaining the container > version of a running task. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4902) Add authentication to libprocess endpoints
[
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291398#comment-15291398
]
Greg Mann commented on MESOS-4902:
--
A couple follow-up patches here to fix endpoint help strings:
https://reviews.apache.org/r/46900/
https://reviews.apache.org/r/46901/
> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> Adding HTTP authentication to these endpoints is a bit more complicated
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the
> same instance of libprocess for both master and agent, different default
> authentication realms must be used for master/agent so that HTTP
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to
> permit the use of different authentication realms for the master and agent
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and
> always enable or disable HTTP authentication for *both* the master and agent
> in tests. However, this wouldn't allow us to test scenarios where HTTP
> authentication is enabled on one but disabled on the other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5414:
--
Shepherd: Till Toenshoff
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Kevin Klues
>Priority: Blocker
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5414:
--
Assignee: Kevin Klues
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Kevin Klues
>Priority: Blocker
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291358#comment-15291358
]
Kevin Klues commented on MESOS-5414:
https://reviews.apache.org/r/47601/
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Priority: Blocker
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5406) Validate ACLs on creating an instance of local authorizer.
[
https://issues.apache.org/jira/browse/MESOS-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-5406:
--
Shepherd: Adam B
Component/s: security
> Validate ACLs on creating an instance of local authorizer.
> --
>
> Key: MESOS-5406
> URL: https://issues.apache.org/jira/browse/MESOS-5406
> Project: Mesos
> Issue Type: Improvement
> Components: security
>Reporter: Alexander Rukletsov
>Assignee: Jay Guo
> Labels: mesosphere, security
>
> Some combinations of ACLs are not allowed, for example, specifying both
> {{SetQuota}} and {{UpdateQuota}}. We should capture such issues and error out
> early.
> This ticket aims to add as many validations as possible to a dedicated
> {{validate()}} routine, instead of having them implicitly in the codebase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4135) Labels are not return in statusUpdate TaskStatus
[ https://issues.apache.org/jira/browse/MESOS-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291201#comment-15291201 ] Shuai Lin commented on MESOS-4135: -- Hi [~srbrahma] , is there any update on this ticket? I need the feature and would like to work on it if you're busy with other things. > Labels are not return in statusUpdate TaskStatus > > > Key: MESOS-4135 > URL: https://issues.apache.org/jira/browse/MESOS-4135 > Project: Mesos > Issue Type: Bug > Components: framework, master >Affects Versions: 0.25.0 >Reporter: Felix Hupfeld >Assignee: Srinivas >Priority: Minor > > Labels that were set in the task's TaskInfo upon creation are not returned in > statusUpdate TaskStatus messages. > This restricts their usefulness. Use case would be maintaining the container > version of a running task. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5413) `network/cni` isolator should skip the bind mounting of the CNI network information root directory if possible
[
https://issues.apache.org/jira/browse/MESOS-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291179#comment-15291179
]
Qian Zhang commented on MESOS-5413:
---
RR: https://reviews.apache.org/r/47594/
> `network/cni` isolator should skip the bind mounting of the CNI network
> information root directory if possible
> --
>
> Key: MESOS-5413
> URL: https://issues.apache.org/jira/browse/MESOS-5413
> Project: Mesos
> Issue Type: Bug
>Reporter: Qian Zhang
>Assignee: Qian Zhang
>
> Currently in the create() method `network/cni` isolator, for the CNI network
> information root directory (i.e., {{/var/run/mesos/isolators/network/cni}}),
> we do a self bind mount and make sure it is a shared mount of its own peer
> group. However, we should not do a self bind mount if the mount containing
> the CNI network information root directory is already a shared mount in its
> own share peer group, just like what we did for `filesystem/linux` isolator
> in [MESOS-5239 | https://issues.apache.org/jira/browse/MESOS-5239].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291133#comment-15291133
]
Guangya Liu commented on MESOS-5414:
Thanks Till, we also have a workaround for now by removing the following code
in configure.ac
{code}
LIBS="$LIBS -lelf" # For stout/elf.hpp.
{code}
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Priority: Blocker
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5414) configure failed on ubuntu and centos
[
https://issues.apache.org/jira/browse/MESOS-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291121#comment-15291121
]
Till Toenshoff commented on MESOS-5414:
---
Thanks for posting this issue. We are aware and have fixes in place already.
Reviewboard's outage however currently prevents us from getting it committed
right now.
> configure failed on ubuntu and centos
> -
>
> Key: MESOS-5414
> URL: https://issues.apache.org/jira/browse/MESOS-5414
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Priority: Blocker
>
> Check out latest code.
> {code}
> ./bootstrap
> mkdir build
> cd build
> ../configure
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> configure: Setting up build environment for x86_64 linux-gnu
> checking for backtrace in -lunwind... no
> checking for main in -lgflags... no
> checking for gzread in -lz... no
> configure: error: cannot find libz
> ---
> libz is required for mesos to build.
> ---
> {code}
> Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
> [~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5414) configure failed on ubuntu and centos
Guangya Liu created MESOS-5414:
--
Summary: configure failed on ubuntu and centos
Key: MESOS-5414
URL: https://issues.apache.org/jira/browse/MESOS-5414
Project: Mesos
Issue Type: Bug
Reporter: Guangya Liu
Priority: Blocker
Check out latest code.
{code}
./bootstrap
mkdir build
cd build
../configure
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
configure: Setting up build environment for x86_64 linux-gnu
checking for backtrace in -lunwind... no
checking for main in -lgflags... no
checking for gzread in -lz... no
configure: error: cannot find libz
---
libz is required for mesos to build.
---
{code}
Seems this was caused by https://reviews.apache.org/r/47484/ cc [~bmahler]
[~klueska]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5413) `network/cni` isolator should skip the bind mounting of the CNI network information root directory if possible
Qian Zhang created MESOS-5413:
-
Summary: `network/cni` isolator should skip the bind mounting of
the CNI network information root directory if possible
Key: MESOS-5413
URL: https://issues.apache.org/jira/browse/MESOS-5413
Project: Mesos
Issue Type: Bug
Reporter: Qian Zhang
Assignee: Qian Zhang
Currently in the create() method `network/cni` isolator, for the CNI network
information root directory (i.e., {{/var/run/mesos/isolators/network/cni}}), we
do a self bind mount and make sure it is a shared mount of its own peer group.
However, we should not do a self bind mount if the mount containing the CNI
network information root directory is already a shared mount in its own share
peer group, just like what we did for `filesystem/linux` isolator in
[MESOS-5239 | https://issues.apache.org/jira/browse/MESOS-5239].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3690) Make Apache Mesos' website mobile friendly
[ https://issues.apache.org/jira/browse/MESOS-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3690: Assignee: Freddy Ayuso-Henson > Make Apache Mesos' website mobile friendly > -- > > Key: MESOS-3690 > URL: https://issues.apache.org/jira/browse/MESOS-3690 > Project: Mesos > Issue Type: Improvement > Components: project website >Reporter: Freddy Ayuso-Henson >Assignee: Freddy Ayuso-Henson >Priority: Minor > Attachments: home_mobile.gif, home_pc.gif, home_tablet.gif, > mesos-screenshot-mobile.png, mesos-screenshot-mobile1.png, > mesos-screenshot.png > > > Changes to the project website: > - Support smaller screens/devices (mobile) > - Limit images' max width when displayed > - Update Bootstrap version > - Other smaller changes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation
[ https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290767#comment-15290767 ] ASF GitHub Bot commented on MESOS-3139: --- Github user rukletsov commented on the pull request: https://github.com/apache/mesos/pull/105#issuecomment-220271611 CC @hausdorff > Incorporate CMake into standard documentation > - > > Key: MESOS-3139 > URL: https://issues.apache.org/jira/browse/MESOS-3139 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: build, cmake, mesosphere > > Right now it's anyone's guess how to build with CMake. If we want people to > use it, we should put up documentation. The central challenge is that the > CMake instructions will be slightly different for different platforms. > For example, on Linux, the gist of the build is basically the same as > autotools; you pull down the system dependencies (like APR, _etc_.), and then: > ``` > ./bootstrap > mkdir build-cmake && cd build-cmake > cmake .. > make > ``` > But, on Windows, it will be somewhat more complicated. There is no bootstrap > step, for example, because Windows doesn't have bash natively. And even when > we put that in, you'll still have to build the glog stuff out-of-band because > CMake has no way of booting up Visual Studio and calling "build." > So practically, we need to figure out: > * What our build story is for different platforms > * Write specific instructions for our "core" target platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake
[ https://issues.apache.org/jira/browse/MESOS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290768#comment-15290768 ] ASF GitHub Bot commented on MESOS-3932: --- Github user rukletsov commented on the pull request: https://github.com/apache/mesos/pull/104#issuecomment-220271622 CC @hausdorff > Silence Boost compiler warnings with CMake > -- > > Key: MESOS-3932 > URL: https://issues.apache.org/jira/browse/MESOS-3932 > Project: Mesos > Issue Type: Bug >Reporter: Neil Conway >Priority: Minor > Labels: cmake, mesosphere > > Per MESOS-3799, we should silence at least two kinds of compiler warning > fixes when including the Boost headers: > * Add -Wno-unused-local-typedefs to CXXFLAGS > * Use -isystem when including Boost to avoid deprecation warnings for use of > auto_ptr > I believe we technically need both, IIRC because some other depedencies pull > in Boost using their own -I flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5335) Add authorization to GET /weights.
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5335: --- Summary: Add authorization to GET /weights. (was: Add authorization to GET /weights) > Add authorization to GET /weights. > -- > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B >Assignee: zhou xing > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5316) Authenticate the agent's '/containers' endpoint.
[
https://issues.apache.org/jira/browse/MESOS-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-5316:
---
Summary: Authenticate the agent's '/containers' endpoint. (was:
Authenticate the agent's '/containers' endpoint)
> Authenticate the agent's '/containers' endpoint.
>
>
> Key: MESOS-5316
> URL: https://issues.apache.org/jira/browse/MESOS-5316
> Project: Mesos
> Issue Type: Improvement
> Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
> Labels: authentication, mesosphere
> Fix For: 0.29.0
>
>
> The {{/containers}} endpoint was recently added to the agent. Authentication
> should be enabled on this endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4785) Reorganize ACL subject/object descriptions.
[ https://issues.apache.org/jira/browse/MESOS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-4785: --- Summary: Reorganize ACL subject/object descriptions. (was: Reorganize ACL subject/object descriptions) > Reorganize ACL subject/object descriptions. > --- > > Key: MESOS-4785 > URL: https://issues.apache.org/jira/browse/MESOS-4785 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Greg Mann >Assignee: Alexander Rojas >Priority: Blocker > Labels: documentation, mesosphere, security > Fix For: 0.29.0 > > > The authorization documentation would benefit from a reorganization of the > ACL subject/object descriptions. Instead of simple lists of the available > subjects and objects, it would be nice to see a table showing which subject > and object is used with each action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5336) Add authorization to GET /quota.
[ https://issues.apache.org/jira/browse/MESOS-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-5336: --- Summary: Add authorization to GET /quota. (was: Add authorization to GET /quota) > Add authorization to GET /quota. > > > Key: MESOS-5336 > URL: https://issues.apache.org/jira/browse/MESOS-5336 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B >Assignee: Zhitao Li > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can set/remove quota for particular > roles, but even knowing of the existence of these roles (let alone their > quotas) may be sensitive information. We should add authz around GET > operations on /quota. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5297) Add authorization to the master's "/flags" endpoint.
[
https://issues.apache.org/jira/browse/MESOS-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-5297:
---
Summary: Add authorization to the master's "/flags" endpoint. (was: Add
authorization to the master's "/flags" endpoint)
> Add authorization to the master's "/flags" endpoint.
>
>
> Key: MESOS-5297
> URL: https://issues.apache.org/jira/browse/MESOS-5297
> Project: Mesos
> Issue Type: Task
>Reporter: Jan Schlicht
>Assignee: Jan Schlicht
> Labels: authorization, mesosphere, security
> Fix For: 0.29.0
>
>
> Coarse HTTP endpoint authorization using the {{GET_ENDPOINT_WITH_PATH}} ACL
> rule needs to be added to the "/flags" endpoint of the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5317) Authorize the agent's '/containers' endpoint.
[
https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-5317:
---
Summary: Authorize the agent's '/containers' endpoint. (was: Authorize the
agent's '/containers' endpoint)
> Authorize the agent's '/containers' endpoint.
> -
>
> Key: MESOS-5317
> URL: https://issues.apache.org/jira/browse/MESOS-5317
> Project: Mesos
> Issue Type: Improvement
> Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
> Labels: authorization, mesosphere
> Fix For: 0.29.0
>
>
> After the agent's {{/containers}} endpoint is authenticated, we should
> enabled authorization as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5317) Authorize the agent's '/containers' endpoint
[
https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-5317:
---
Sprint: Mesosphere Sprint 35
> Authorize the agent's '/containers' endpoint
>
>
> Key: MESOS-5317
> URL: https://issues.apache.org/jira/browse/MESOS-5317
> Project: Mesos
> Issue Type: Improvement
> Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
> Labels: authorization, mesosphere
> Fix For: 0.29.0
>
>
> After the agent's {{/containers}} endpoint is authenticated, we should
> enabled authorization as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5317) Authorize the agent's '/containers' endpoint
[
https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-5317:
---
Shepherd: Alexander Rukletsov
> Authorize the agent's '/containers' endpoint
>
>
> Key: MESOS-5317
> URL: https://issues.apache.org/jira/browse/MESOS-5317
> Project: Mesos
> Issue Type: Improvement
> Components: security, slave
>Reporter: Greg Mann
>Assignee: Abhishek Dasgupta
> Labels: authorization, mesosphere
> Fix For: 0.29.0
>
>
> After the agent's {{/containers}} endpoint is authenticated, we should
> enabled authorization as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5336) Add authorization to GET /quota
[
https://issues.apache.org/jira/browse/MESOS-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286541#comment-15286541
]
Alexander Rukletsov edited comment on MESOS-5336 at 5/19/16 7:44 AM:
-
{noformat}
Commit: 8e616a03cdba5dbc7975f003c2bd0d3dd5f4da19 [8e616a0]
Author: Zhitao Li
Date: 17 May 2016 11:52:18 CEST
Committer: Alexander Rukletsov
Commit Date: 17 May 2016 14:40:20 CEST
Added authorization for GET '/quota' master endpoint.
GET access to the '/quota' master endpoint is authorized using the
newly introduced 'GET_QUOTA_WITH_ROLE' action. The response JSON is
filtered on per-role basis.
Review: https://reviews.apache.org/r/47274/
{noformat}
{noformat}
Commit: 71e5099c55bb5fd064ef5efe59ed780ad1e93060 [71e5099]
Author: Zhitao Li zhitaoli...@gmail.com
Date: 19 May 2016 09:04:20 CEST
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 19 May 2016 09:39:37 CEST
Documented quota authorization changes.
Review: https://reviews.apache.org/r/47400/
{noformat}
was (Author: alexr):
{noformat}
Commit: 8e616a03cdba5dbc7975f003c2bd0d3dd5f4da19 [8e616a0]
Author: Zhitao Li
Date: 17 May 2016 11:52:18 CEST
Committer: Alexander Rukletsov
Commit Date: 17 May 2016 14:40:20 CEST
Added authorization for GET '/quota' master endpoint.
GET access to the '/quota' master endpoint is authorized using the
newly introduced 'GET_QUOTA_WITH_ROLE' action. The response JSON is
filtered on per-role basis.
Review: https://reviews.apache.org/r/47274/
{noformat}
> Add authorization to GET /quota
> ---
>
> Key: MESOS-5336
> URL: https://issues.apache.org/jira/browse/MESOS-5336
> Project: Mesos
> Issue Type: Improvement
> Components: master, security
>Reporter: Adam B
>Assignee: Zhitao Li
> Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We already authorize which http users can set/remove quota for particular
> roles, but even knowing of the existence of these roles (let alone their
> quotas) may be sensitive information. We should add authz around GET
> operations on /quota.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289240#comment-15289240
]
Alexander Rukletsov edited comment on MESOS-5155 at 5/19/16 7:43 AM:
-
{noformat}
Commit: a28917f188183a4be1c974fc61ef20797cf255af [a28917f]
Author: Zhitao Li
Date: 18 May 2016 16:17:11 CEST
Committer: Alexander Rukletsov
Commit Date: 18 May 2016 18:21:40 CEST
Used UPDATE_QUOTA_WITH_ROLE for both quota set and remove.
To consolidate authorization actions for quota, we introduce a new
authorization action `UPDATE_QUOTA_WITH_ROLE` and corresponding
ACL. They new action and ACL should be used instead of now deprecated
`SET_QUOTA_WITH_ROLE` and `DESTROY_QUOTA_WITH_PRINCIPAL`. Until the
end of the deprecation cycle, we will be using both combinations by
querying the authorizer twice.
Review: https://reviews.apache.org/r/47399/
{noformat}
{noformat}
Commit: 71e5099c55bb5fd064ef5efe59ed780ad1e93060 [71e5099]
Author: Zhitao Li zhitaoli...@gmail.com
Date: 19 May 2016 09:04:20 CEST
Committer: Alexander Rukletsov al...@apache.org
Commit Date: 19 May 2016 09:39:37 CEST
Documented quota authorization changes.
Review: https://reviews.apache.org/r/47400/
{noformat}
was (Author: alexr):
{noformat}
Commit: a28917f188183a4be1c974fc61ef20797cf255af [a28917f]
Author: Zhitao Li
Date: 18 May 2016 16:17:11 CEST
Committer: Alexander Rukletsov
Commit Date: 18 May 2016 18:21:40 CEST
Used UPDATE_QUOTA_WITH_ROLE for both quota set and remove.
To consolidate authorization actions for quota, we introduce a new
authorization action `UPDATE_QUOTA_WITH_ROLE` and corresponding
ACL. They new action and ACL should be used instead of now deprecated
`SET_QUOTA_WITH_ROLE` and `DESTROY_QUOTA_WITH_PRINCIPAL`. Until the
end of the deprecation cycle, we will be using both combinations by
querying the authorizer twice.
Review: https://reviews.apache.org/r/47399/
{noformat}
> Consolidate authorization actions for quota.
>
>
> Key: MESOS-5155
> URL: https://issues.apache.org/jira/browse/MESOS-5155
> Project: Mesos
> Issue Type: Improvement
>Reporter: Alexander Rukletsov
>Assignee: Zhitao Li
> Labels: mesosphere
>
> We should have just a single authz action: {{UPDATE_QUOTA_WITH_ROLE}}. It was
> a mistake in retrospect to introduce multiple actions.
> Actions that are not symmetrical are register/teardown and dynamic
> reservations. The way they are implemented in this way is because entities
> that do one action differ from entities that do the other. For example,
> register framework is issued by a framework, teardown by an operator. What is
> a good way to identify a framework? A role it runs in, which may be different
> each launch and makes no sense in multi-role frameworks setup or better a
> sort of a group id, which is its principal. For dynamic reservations and
> persistent volumes, they can be both issued by frameworks and operators,
> hence similar reasoning applies.
> Now, quota is associated with a role and set only by operators. Do we need to
> care about principals that set it? Not that much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5411) SSL support in Mesos Packages
[ https://issues.apache.org/jira/browse/MESOS-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290626#comment-15290626 ] Piotr Śliwka commented on MESOS-5411: - Thanks for the info, [~vinodkone]! > SSL support in Mesos Packages > - > > Key: MESOS-5411 > URL: https://issues.apache.org/jira/browse/MESOS-5411 > Project: Mesos > Issue Type: Improvement >Reporter: Piotr Śliwka >Priority: Minor > > It would be nice to have the SSL support (as described in > http://mesos.apache.org/documentation/latest/ssl/) compiled into official > deb/rpm packages, so that using this feature would not require custom builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qian Zhang updated MESOS-5408: -- Comment: was deleted (was: Sure! Regards,Qian Zhang (张 乾) - Original message - From: "Vinod Kone (JIRA)" To: Qian AZ Zhang/China/IBM@IBMCN Cc: Subject: [jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint Date: Thu, May 19, 2016 8:43 AM [ [1]https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290195#comment-15290195 ] Vinod Kone commented on MESOS-5408: --- Great. Please send an email to dev/user list as a heads up just in case and also update the CHANGELOG. -- This message was sent by Atlassian JIRA (v6.3.4#6332) [1] https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290195#comment-15290195 [2] https://issues.apache.org/jira/browse/MESOS-5408 ) > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290610#comment-15290610 ] Qian Zhang commented on MESOS-5408: --- RR: https://reviews.apache.org/r/47581/ > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5335) Add authorization to GET /weights
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-5335: -- Shepherd: Adam B (was: Alexander Rukletsov) > Add authorization to GET /weights > - > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B >Assignee: zhou xing > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3690) Make Apache Mesos' website mobile friendly
[ https://issues.apache.org/jira/browse/MESOS-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freddy Ayuso-Henson updated MESOS-3690: --- Attachment: mesos-screenshot-mobile.png mesos-screenshot-mobile1.png mesos-screenshot.png > Make Apache Mesos' website mobile friendly > -- > > Key: MESOS-3690 > URL: https://issues.apache.org/jira/browse/MESOS-3690 > Project: Mesos > Issue Type: Improvement > Components: project website >Reporter: Freddy Ayuso-Henson >Priority: Minor > Attachments: home_mobile.gif, home_pc.gif, home_tablet.gif, > mesos-screenshot-mobile.png, mesos-screenshot-mobile1.png, > mesos-screenshot.png > > > Changes to the project website: > - Support smaller screens/devices (mobile) > - Limit images' max width when displayed > - Update Bootstrap version > - Other smaller changes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
