[jira] [Commented] (MESOS-4877) Mesos containerizer can't handle top level docker image like "alpine" (must use "library/alpine")
[
https://issues.apache.org/jira/browse/MESOS-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203820#comment-15203820
]
Gilbert Song commented on MESOS-4877:
-
Re-post all reviewable patches here:
https://reviews.apache.org/r/44672/
https://reviews.apache.org/r/44673/
> Mesos containerizer can't handle top level docker image like "alpine" (must
> use "library/alpine")
> -
>
> Key: MESOS-4877
> URL: https://issues.apache.org/jira/browse/MESOS-4877
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.27.0, 0.27.1
>Reporter: Shuai Lin
>Assignee: Gilbert Song
> Fix For: 0.28.1
>
>
> This can be demonstrated with the {{mesos-execute}} command:
> # Docker containerizer with image {{alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=docker
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{alpine}}: failure
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=mesos
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{library/alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=library/alpine
> --containerizer=mesos --name=just-a-test --command="sleep 1000"
> --master=localhost:5050
> {code}
> In the slave logs:
> {code}
> ea-4460-83
> 9c-838da86af34c-0007'
> I0306 16:32:41.418269 3403 metadata_manager.cpp:159] Looking for image
> 'alpine:latest'
> I0306 16:32:41.418699 3403 registry_puller.cpp:194] Pulling image
> 'alpine:latest' from
> 'docker-manifest://registry-1.docker.io:443alpine?latest#https' to
> '/tmp/mesos-test
> /store/docker/staging/ka7MlQ'
> E0306 16:32:43.098131 3400 slave.cpp:3773] Container
> '4bf9132d-9a57-4baa-a78c-e7164e93ace6' for executor 'just-a-test' of
> framework 4f055c6f-1bea-4460-839c-838da86af34c-0
> 007 failed to start: Collect failed: Unexpected HTTP response '401
> Unauthorized
> {code}
> curl command executed:
> {code}
> $ sudo sysdig -A -p "*%evt.time %proc.cmdline" evt.type=execve and
> proc.name=curl
>16:42:53.198998042 curl -s -S -L -D -
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> 16:42:53.784958541 curl -s -S -L -D -
> https://auth.docker.io/token?service=registry.docker.io&scope=repository:alpine:pull
> 16:42:54.294192024 curl -s -S -L -D - -H Authorization: Bearer
> eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDTHpDQ0FkU2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0Uk5Gb3pPa2RYTjBrNldGUlFSRHBJVFRSUk9rOVVWRmc2TmtGRlF6cFNUVE5ET2tGU01rTTZUMFkzTnpwQ1ZrVkJPa2xHUlVrNlExazFTekFlRncweE5UQTJNalV4T1RVMU5EWmFGdzB4TmpBMk1qUXhPVFUxTkRaYU1FWXhSREJDQmdOVkJBTVRPMGhHU1UwNldGZFZWam8yUVZkSU9sWlpUVEk2TTFnMVREcFNWREkxT2s5VFNrbzZTMVExUmpwWVRsSklPbFJMTmtnNlMxUkxOanBCUVV0VU1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXl2UzIvdEI3T3JlMkVxcGRDeFdtS1NqV1N2VmJ2TWUrWGVFTUNVMDByQjI0akNiUVhreFdmOSs0MUxQMlZNQ29BK0RMRkIwVjBGZGdwajlOWU5rL2pxT0JzakNCcnpBT0JnTlZIUThCQWY4RUJBTUNBSUF3RHdZRFZSMGxCQWd3QmdZRVZSMGxBREJFQmdOVkhRNEVQUVE3U0VaSlRUcFlWMVZXT2paQlYwZzZWbGxOTWpveldEVk1PbEpVTWpVNlQxTktTanBMVkRWR09saE9Va2c2VkVzMlNEcExWRXMyT2tGQlMxUXdSZ1lEVlIwakJEOHdQWUE3VVRSYU16cEhWemRKT2xoVVVFUTZTRTAwVVRwUFZGUllPalpCUlVNNlVrMHpRenBCVWpKRE9rOUdOemM2UWxaRlFUcEpSa1ZKT2tOWk5Vc3dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBTXZiT2h4cHhrTktqSDRhMFBNS0lFdXRmTjZtRDFvMWs4ZEJOVGxuWVFudkFpRUF0YVJGSGJSR2o4ZlVSSzZ4UVJHRURvQm1ZZ3dZelR3Z3BMaGJBZzNOUmFvPSJdfQ.eyJhY2Nlc3MiOltdLCJhdWQiOiJyZWdpc3RyeS5kb2NrZXIuaW8iLCJleHAiOjE0NTcyODI4NzQsImlhdCI6MTQ1NzI4MjU3NCwiaXNzIjoiYXV0aC5kb2NrZXIuaW8iLCJqdGkiOiJaOGtyNXZXNEJMWkNIRS1IcVJIaCIsIm5iZiI6MTQ1NzI4MjU3NCwic3ViIjoiIn0.C2wtJq_P-m0buPARhmQjDfh6ztIAhcvgN3tfWIZEClSgXlVQ_sAQXAALNZKwAQL2Chj7NpHX--0GW-aeL_28Aw
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> {code}
> Also got the same result with {{ubuntu}} docker image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4877) Mesos containerizer can't handle top level docker image like "alpine" (must use "library/alpine")
[
https://issues.apache.org/jira/browse/MESOS-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203819#comment-15203819
]
Gilbert Song commented on MESOS-4877:
-
Thanks, [~lins05]!
> Mesos containerizer can't handle top level docker image like "alpine" (must
> use "library/alpine")
> -
>
> Key: MESOS-4877
> URL: https://issues.apache.org/jira/browse/MESOS-4877
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.27.0, 0.27.1
>Reporter: Shuai Lin
>Assignee: Gilbert Song
> Fix For: 0.28.1
>
>
> This can be demonstrated with the {{mesos-execute}} command:
> # Docker containerizer with image {{alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=docker
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{alpine}}: failure
> {code}
> sudo ./build/src/mesos-execute --docker_image=alpine --containerizer=mesos
> --name=just-a-test --command="sleep 1000" --master=localhost:5050
> {code}
> # Mesos containerizer with image {{library/alpine}}: success
> {code}
> sudo ./build/src/mesos-execute --docker_image=library/alpine
> --containerizer=mesos --name=just-a-test --command="sleep 1000"
> --master=localhost:5050
> {code}
> In the slave logs:
> {code}
> ea-4460-83
> 9c-838da86af34c-0007'
> I0306 16:32:41.418269 3403 metadata_manager.cpp:159] Looking for image
> 'alpine:latest'
> I0306 16:32:41.418699 3403 registry_puller.cpp:194] Pulling image
> 'alpine:latest' from
> 'docker-manifest://registry-1.docker.io:443alpine?latest#https' to
> '/tmp/mesos-test
> /store/docker/staging/ka7MlQ'
> E0306 16:32:43.098131 3400 slave.cpp:3773] Container
> '4bf9132d-9a57-4baa-a78c-e7164e93ace6' for executor 'just-a-test' of
> framework 4f055c6f-1bea-4460-839c-838da86af34c-0
> 007 failed to start: Collect failed: Unexpected HTTP response '401
> Unauthorized
> {code}
> curl command executed:
> {code}
> $ sudo sysdig -A -p "*%evt.time %proc.cmdline" evt.type=execve and
> proc.name=curl
>16:42:53.198998042 curl -s -S -L -D -
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> 16:42:53.784958541 curl -s -S -L -D -
> https://auth.docker.io/token?service=registry.docker.io&scope=repository:alpine:pull
> 16:42:54.294192024 curl -s -S -L -D - -H Authorization: Bearer
> eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDTHpDQ0FkU2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0Uk5Gb3pPa2RYTjBrNldGUlFSRHBJVFRSUk9rOVVWRmc2TmtGRlF6cFNUVE5ET2tGU01rTTZUMFkzTnpwQ1ZrVkJPa2xHUlVrNlExazFTekFlRncweE5UQTJNalV4T1RVMU5EWmFGdzB4TmpBMk1qUXhPVFUxTkRaYU1FWXhSREJDQmdOVkJBTVRPMGhHU1UwNldGZFZWam8yUVZkSU9sWlpUVEk2TTFnMVREcFNWREkxT2s5VFNrbzZTMVExUmpwWVRsSklPbFJMTmtnNlMxUkxOanBCUVV0VU1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXl2UzIvdEI3T3JlMkVxcGRDeFdtS1NqV1N2VmJ2TWUrWGVFTUNVMDByQjI0akNiUVhreFdmOSs0MUxQMlZNQ29BK0RMRkIwVjBGZGdwajlOWU5rL2pxT0JzakNCcnpBT0JnTlZIUThCQWY4RUJBTUNBSUF3RHdZRFZSMGxCQWd3QmdZRVZSMGxBREJFQmdOVkhRNEVQUVE3U0VaSlRUcFlWMVZXT2paQlYwZzZWbGxOTWpveldEVk1PbEpVTWpVNlQxTktTanBMVkRWR09saE9Va2c2VkVzMlNEcExWRXMyT2tGQlMxUXdSZ1lEVlIwakJEOHdQWUE3VVRSYU16cEhWemRKT2xoVVVFUTZTRTAwVVRwUFZGUllPalpCUlVNNlVrMHpRenBCVWpKRE9rOUdOemM2UWxaRlFUcEpSa1ZKT2tOWk5Vc3dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBTXZiT2h4cHhrTktqSDRhMFBNS0lFdXRmTjZtRDFvMWs4ZEJOVGxuWVFudkFpRUF0YVJGSGJSR2o4ZlVSSzZ4UVJHRURvQm1ZZ3dZelR3Z3BMaGJBZzNOUmFvPSJdfQ.eyJhY2Nlc3MiOltdLCJhdWQiOiJyZWdpc3RyeS5kb2NrZXIuaW8iLCJleHAiOjE0NTcyODI4NzQsImlhdCI6MTQ1NzI4MjU3NCwiaXNzIjoiYXV0aC5kb2NrZXIuaW8iLCJqdGkiOiJaOGtyNXZXNEJMWkNIRS1IcVJIaCIsIm5iZiI6MTQ1NzI4MjU3NCwic3ViIjoiIn0.C2wtJq_P-m0buPARhmQjDfh6ztIAhcvgN3tfWIZEClSgXlVQ_sAQXAALNZKwAQL2Chj7NpHX--0GW-aeL_28Aw
> https://registry-1.docker.io:443/v2/alpine/manifests/latest
> {code}
> Also got the same result with {{ubuntu}} docker image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4802) Update leveldb patch file to suport PowerPC LE
[ https://issues.apache.org/jira/browse/MESOS-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203652#comment-15203652 ] Chen Zhiwei commented on MESOS-4802: Upgrade to 1.18 will not need to carry power related patches, but still need a patch file to remove dependencies just like now. Should I upgrade it? > Update leveldb patch file to suport PowerPC LE > -- > > Key: MESOS-4802 > URL: https://issues.apache.org/jira/browse/MESOS-4802 > Project: Mesos > Issue Type: Improvement >Reporter: Qian Zhang >Assignee: Chen Zhiwei > > See: https://github.com/google/leveldb/releases/tag/v1.18 for improvements / > bug fixes. > The motivation is that leveldb 1.18 has officially supported IBM Power > (ppc64le), so this is needed by > [MESOS-4312|https://issues.apache.org/jira/browse/MESOS-4312]. > Update: Since someone updated leveldb to 1.4, so I only update the patch file > to support PowerPC LE. Because I don't think upgrade 3rdparty library > frequently is a good thing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4885) Unzip should force overwrite
[ https://issues.apache.org/jira/browse/MESOS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203649#comment-15203649 ] Jie Yu commented on MESOS-4885: --- commit ecf5798312629026cead17011b3098a9ee5e55ad Author: Tomasz Janiszewski Date: Sun Mar 20 19:25:25 2016 -0700 Made `unzip` overwrite existing files without prompting. Review: https://reviews.apache.org/r/45057/ > Unzip should force overwrite > > > Key: MESOS-4885 > URL: https://issues.apache.org/jira/browse/MESOS-4885 > Project: Mesos > Issue Type: Bug > Components: fetcher >Reporter: Tomasz Janiszewski >Assignee: Tomasz Janiszewski >Priority: Trivial > Fix For: 0.29.0 > > > Consider situation when zip file is malformed and contains duplicated files . > When fetcher downloads malformed zip file, that contains duplicated files > (e.g., dist zips generated by gradle could have duplicated files in libs dir) > and try to uncompress it, deployment hang in staged phase because unzip > prompt if file should be replaced. unzip should overrite this file or break > with error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4885) Unzip should force overwrite
[ https://issues.apache.org/jira/browse/MESOS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4885: -- Shepherd: Jie Yu > Unzip should force overwrite > > > Key: MESOS-4885 > URL: https://issues.apache.org/jira/browse/MESOS-4885 > Project: Mesos > Issue Type: Bug > Components: fetcher >Reporter: Tomasz Janiszewski >Assignee: Tomasz Janiszewski >Priority: Trivial > > Consider situation when zip file is malformed and contains duplicated files . > When fetcher downloads malformed zip file, that contains duplicated files > (e.g., dist zips generated by gradle could have duplicated files in libs dir) > and try to uncompress it, deployment hang in staged phase because unzip > prompt if file should be replaced. unzip should overrite this file or break > with error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4987) The resources is not full allocated because of Quota
[ https://issues.apache.org/jira/browse/MESOS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203629#comment-15203629 ] Klaus Ma commented on MESOS-4987: - After checked the history, it's design behaviour in "https://reviews.apache.org/r/42835";. But it seems the resources will not be full used until "revocable by default", will it be too long for users? > The resources is not full allocated because of Quota > > > Key: MESOS-4987 > URL: https://issues.apache.org/jira/browse/MESOS-4987 > Project: Mesos > Issue Type: Bug >Reporter: Klaus Ma > Attachments: test.diff > > > The following case is failed, please correct me is any misunderstanding: > 1. Set Quota to "cpu:1;mem:128" > 2. Add a framework > 3. Add an agent (cpu:8;mem:256); the framework will get an allocation > 4. Add another agent (cpu:8;mem:256); > 5. Waiting for the allocation. <=== The test failed here because of > expired. > cc [~bmahler], [~mcypark], [~alexr] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203418#comment-15203418 ] haosdent commented on MESOS-4697: - [~idownes] We public the design doc in https://docs.google.com/document/d/1rAAzymtY5tcXY9X-Ryz6tEFeWA1_VBhnFYoE7M2kbvk/edit?usp=sharing , looking forward your comments and suggestions. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a different hierarchy. > This gradually become not true with unified cgroup hierarchy introduced in > kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4849) Add agent flags for HTTP authentication
[
https://issues.apache.org/jira/browse/MESOS-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185518#comment-15185518
]
Greg Mann edited comment on MESOS-4849 at 3/20/16 6:21 PM:
---
Reviews here:
https://reviews.apache.org/r/44678/
https://reviews.apache.org/r/44703/
https://reviews.apache.org/r/44515/
https://reviews.apache.org/r/44523/
https://reviews.apache.org/r/45088/
was (Author: greggomann):
Reviews here:
https://reviews.apache.org/r/44678/
https://reviews.apache.org/r/44703/
https://reviews.apache.org/r/44515/
https://reviews.apache.org/r/44523/
> Add agent flags for HTTP authentication
> ---
>
> Key: MESOS-4849
> URL: https://issues.apache.org/jira/browse/MESOS-4849
> Project: Mesos
> Issue Type: Task
> Components: security, slave
>Reporter: Adam B
>Assignee: Greg Mann
> Labels: mesosphere, security
>
> Flags should be added to the agent to:
> 1. Enable HTTP authentication ({{--authenticate_http}})
> 2. Specify credentials ({{--http_credentials}})
> 3. Specify HTTP authenticators ({{--authenticators}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4849) Add agent flags for HTTP authentication
[
https://issues.apache.org/jira/browse/MESOS-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185518#comment-15185518
]
Greg Mann edited comment on MESOS-4849 at 3/20/16 5:33 PM:
---
Reviews here:
https://reviews.apache.org/r/44678/
https://reviews.apache.org/r/44703/
https://reviews.apache.org/r/44515/
https://reviews.apache.org/r/44523/
was (Author: greggomann):
Reviews here:
https://reviews.apache.org/r/44678/
https://reviews.apache.org/r/44703/
https://reviews.apache.org/r/44515/
https://reviews.apache.org/r/44523/
https://reviews.apache.org/r/44989/
> Add agent flags for HTTP authentication
> ---
>
> Key: MESOS-4849
> URL: https://issues.apache.org/jira/browse/MESOS-4849
> Project: Mesos
> Issue Type: Task
> Components: security, slave
>Reporter: Adam B
>Assignee: Greg Mann
> Labels: mesosphere, security
>
> Flags should be added to the agent to:
> 1. Enable HTTP authentication ({{--authenticate_http}})
> 2. Specify credentials ({{--http_credentials}})
> 3. Specify HTTP authenticators ({{--authenticators}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4964) curl based docker fetcher fails to decode chunked encoding
[
https://issues.apache.org/jira/browse/MESOS-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu reassigned MESOS-4964:
-
Assignee: Jie Yu
> curl based docker fetcher fails to decode chunked encoding
> --
>
> Key: MESOS-4964
> URL: https://issues.apache.org/jira/browse/MESOS-4964
> Project: Mesos
> Issue Type: Bug
> Components: fetcher
>Reporter: James Peach
>Assignee: Jie Yu
> Labels: mesosphere
>
> If the curl-base fetcher gets a HTTP response that is chunked, the HTTP
> decode fails because the response says it is chunked, but curl is dechunking
> the body to stdout.
> {code}
> E0316 15:23:31.124482 13299 slave.cpp:3773] Container
> 'fa06a5ee-637e-480c-b602-59705b707d85' for executor 'jpeach.10489' of
> framework 96d1191b-cdf0-40f6-8840-e4d4d92a9345-0010 failed to start: Collect
> failed: Failed to decode HTTP responses: Decoding failed
> HTTP/1.1 400 Bad Request
> Server: nginx/1.9.4
> Date: Wed, 16 Mar 2016 22:23:30 GMT
> Content-Type: application/json
> Transfer-Encoding: chunked
> Connection: keep-alive
> X-Artifactory-Id: ae6c9bffd47ec19a:-61ef0a68:1537a605a05:-8000
> {
> "errors" : [ {
> "status" : 400,
> "message" : "Unsupported docker v2 repository request for
> 'docker-registry'"
> } ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4979) os::rmdir does not handle special files (e.g., device, socket).
[ https://issues.apache.org/jira/browse/MESOS-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-4979: -- Labels: mesosphere (was: ) > os::rmdir does not handle special files (e.g., device, socket). > --- > > Key: MESOS-4979 > URL: https://issues.apache.org/jira/browse/MESOS-4979 > Project: Mesos > Issue Type: Bug > Components: stout >Affects Versions: 0.19.0, 0.20.0, 0.21.0, 0.22.0, 0.23.0, 0.24.0, 0.25.0, > 0.26.0, 0.27.0, 0.27.1, 0.27.2 >Reporter: Jie Yu >Assignee: Jojy Varghese >Priority: Blocker > Labels: mesosphere > Fix For: 0.28.0 > > > Stout os::rmdir does not handle special files like device files or socket > files. This could cause failures when GC sandboxes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated MESOS-4969:
---
Summary: improve overlayfs detection (was: improve overlays detection)
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: isolation, volumes
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4988) Excluded reserved resources when got nonRevocable resources in stage 1.
Klaus Ma created MESOS-4988: --- Summary: Excluded reserved resources when got nonRevocable resources in stage 1. Key: MESOS-4988 URL: https://issues.apache.org/jira/browse/MESOS-4988 Project: Mesos Issue Type: Bug Components: allocation Reporter: Klaus Ma Allocator will only allocate non-revocable resources to satify quota. As the reserved resources can not be revocable, it's not necessary to call `nonRevocable()` for reserved resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4621:
Assignee: Yong Tang
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4987) The resources is not full allocated because of Quota
[ https://issues.apache.org/jira/browse/MESOS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Klaus Ma updated MESOS-4987: Attachment: test.diff Append the test case. Found this case when checking the feature interaction with MESOS-4967, I think here's root cause: 1. In stage 1 (for Quota), the allocator will skip the following slaves if quota is satisfied 2. In stage 2 (for DRF), the allocator will also skip unreserved resources in agent if there's a quota for the role (https://github.com/apache/mesos/blob/master/src/master/allocator/mesos/hierarchical.cpp#L1396) > The resources is not full allocated because of Quota > > > Key: MESOS-4987 > URL: https://issues.apache.org/jira/browse/MESOS-4987 > Project: Mesos > Issue Type: Bug >Reporter: Klaus Ma > Attachments: test.diff > > > The following case is failed, please correct me is any misunderstanding: > 1. Set Quota to "cpu:1;mem:128" > 2. Add a framework > 3. Add an agent (cpu:8;mem:256); the framework will get an allocation > 4. Add another agent (cpu:8;mem:256); > 5. Waiting for the allocation. <=== The test failed here because of > expired. > cc [~bmahler], [~mcypark], [~alexr] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4987) The resources is not full allocated because of Quota
Klaus Ma created MESOS-4987: --- Summary: The resources is not full allocated because of Quota Key: MESOS-4987 URL: https://issues.apache.org/jira/browse/MESOS-4987 Project: Mesos Issue Type: Bug Reporter: Klaus Ma The following case is failed, please correct me is any misunderstanding: 1. Set Quota to "cpu:1;mem:128" 2. Add a framework 3. Add an agent (cpu:8;mem:256); the framework will get an allocation 4. Add another agent (cpu:8;mem:256); 5. Waiting for the allocation. <=== The test failed here because of expired. cc [~bmahler], [~mcypark], [~alexr] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4963) Incorrect CXXFLAGS with GCC 6
[
https://issues.apache.org/jira/browse/MESOS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Conway updated MESOS-4963:
---
Component/s: (was: stout)
build
> Incorrect CXXFLAGS with GCC 6
> -
>
> Key: MESOS-4963
> URL: https://issues.apache.org/jira/browse/MESOS-4963
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Neil Conway
>Assignee: Neil Conway
> Labels: mesosphere
>
> {noformat}
> $ head config.log
> [...]
> /mesos-2/configure --enable-optimize --disable-python CC=ccache
> /home/vagrant/local/gcc/bin/gcc CXX=ccache /home/vagrant/local/gcc/bin/g++
> $ ~/local/gcc/bin/g++ --version
> g++ (GCC) 6.0.0 20160227 (experimental)
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ make V=0
> make[2]: Entering directory '/home/vagrant/build-mesos-2-gcc6/src'
> CXX appc/libmesos_no_3rdparty_la-spec.lo
> In file included from
> /mesos-2/3rdparty/libprocess/3rdparty/stout/include/stout/os/shell.hpp:22:0,
> from
> /mesos-2/3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp:56,
> from /mesos-2/src/appc/spec.cpp:17:
> /mesos-2/3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/shell.hpp:
> In instantiation of ‘int os::execlp(const char*, T ...) [with T = {const
> char*, const char*, const char*, char*}]’:
> /mesos-2/3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp:371:52:
>required from here
> /mesos-2/3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/shell.hpp:151:18:
> error: missing sentinel in function call [-Werror=format=]
>return ::execlp(file, t...);
> ^~~~
> cc1plus: all warnings being treated as errors
> Makefile:5584: recipe for target 'appc/libmesos_no_3rdparty_la-spec.lo' failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4033) Add a commit hook for non-ascii charachters
[ https://issues.apache.org/jira/browse/MESOS-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-4033: Assignee: Yong Tang > Add a commit hook for non-ascii charachters > --- > > Key: MESOS-4033 > URL: https://issues.apache.org/jira/browse/MESOS-4033 > Project: Mesos > Issue Type: Task >Reporter: Alexander Rukletsov >Assignee: Yong Tang >Priority: Minor > Labels: mesosphere > > Non-ascii characters invisible in some editors may sneak into the codebase > (see e.g. https://reviews.apache.org/r/40799/). To avoid this, a pre-commit > hook can be added. > Quick searching suggested a simple perl script: > https://superuser.com/questions/417305/how-can-i-identify-non-ascii-characters-from-the-shell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200118#comment-15200118
]
Yan Xu edited comment on MESOS-4969 at 3/17/16 6:35 PM:
{{modprobe -q overlay}} and check exit status sound reasonable to me.
Since this doesn't apply to all filesystems, we can do it in
{{OverlayBackend::create(const Flags&)}} and keep {{Try supported(const
std::string& fsname);}} unchanged.
was (Author: xujyan):
{{modprobe -q overlay}} and check exit status sound reasonable to me.
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: isolation, volumes
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197471#comment-15197471
]
Yong Tang edited comment on MESOS-4621 at 3/16/16 3:11 PM:
---
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway:
# --enable-optimize : [enable_optimize=yes]
# --enable-optimize=yes : [enable_optimize=yes]
# --enable-optimize=no : [enable_optimize=no]
# --disable-optimize : [enable_optimize=no]
was (Author: yongtang):
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway.
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3011) Publish release documentation for major releases on website
[ https://issues.apache.org/jira/browse/MESOS-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-3011: --- Sprint: Mesosphere Sprint 30 (was: Mesosphere Sprint 30, Mesosphere Sprint 31) > Publish release documentation for major releases on website > --- > > Key: MESOS-3011 > URL: https://issues.apache.org/jira/browse/MESOS-3011 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Reporter: Paul Brett >Assignee: Joerg Schad > Labels: documentation, mesosphere > > Currently, the website only provides a single version of the documentation. > We should publish documentation for each release on the website independently > (for example as https://mesos.apache.org/documentation/0.22/index.html, > https://mesos.apache.org/documentation/0.23/index.html) and make latest > redirect to the current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4965) Support resizing of an existing persistent volume
Zhitao Li created MESOS-4965: Summary: Support resizing of an existing persistent volume Key: MESOS-4965 URL: https://issues.apache.org/jira/browse/MESOS-4965 Project: Mesos Issue Type: Improvement Components: volumes Reporter: Zhitao Li We need a mechanism to update the size of a persistent volume. The increase case is generally more interesting to us (as long as there still available disk resource on the same disk). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4605) Upgrading mesos should not (re)enable mesos master or slave
[ https://issues.apache.org/jira/browse/MESOS-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201456#comment-15201456 ] Grégoire Bellon-Gervais commented on MESOS-4605: Just for your information, I have created the following issue : https://github.com/mesosphere/mesos-deb-packaging/issues/70 Thanks for your help. > Upgrading mesos should not (re)enable mesos master or slave > --- > > Key: MESOS-4605 > URL: https://issues.apache.org/jira/browse/MESOS-4605 > Project: Mesos > Issue Type: Bug > Components: general >Affects Versions: 0.27.0 > Environment: debian8 >Reporter: Grégoire Bellon-Gervais >Priority: Minor > > Hello, > I'm under debian 8 and I use official repository to install mesos (and the > deb files) : > deb http://repos.mesosphere.io/debian jessie main > I have 3 mesos masters and 3 mesos slaves. > On masters, mesos slaves are not started (and must not be started), same for > mesos slaves, mesos masters must not be started. > During each upgrade, I have to disable manually after the upgrade the "not > installed component". > Here the log on a mesos slave for example : > > Setting up mesos (0.27.0-0.2.190.debian81) ... > Created symlink from > /etc/systemd/system/multi-user.target.wants/mesos-master.service to > /lib/systemd/system/mesos-master.service. > Processing triggers for libc-bin (2.19-18+deb8u2) ... > ... > So, once upgrade is done, I have to issue the following command : > systemctl disable mesos-master.service > It should not be necessary I think. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-4823) Implement port forwarding in `network/cni` isolator
[ https://issues.apache.org/jira/browse/MESOS-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avinash Sridharan updated MESOS-4823: - Comment: was deleted (was: But how would the CNI isolator know if the underlying plugin has the capability or not? Or for that matter the parameters that it needs to pass to the plugin?) > Implement port forwarding in `network/cni` isolator > --- > > Key: MESOS-4823 > URL: https://issues.apache.org/jira/browse/MESOS-4823 > Project: Mesos > Issue Type: Task > Components: containerization > Environment: linux >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan >Priority: Critical > Labels: mesosphere > > Most docker and appc images wish to expose ports that micro-services are > listening on, to the outside world. When containers are running on bridged > (or ptp) networking this can be achieved by installing port forwarding rules > on the agent (using iptables). This can be done in the `network/cni` > isolator. > The reason we would like this functionality to be implemented in the > `network/cni` isolator, and not a CNI plugin, is that the specifications > currently do not support specifying port forwarding rules. Further, to > install these rules the isolator needs two pieces of information, the exposed > ports and the IP address associated with the container. Bother are available > to the isolator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4964) curl based docker fetcher fails to decode chunked encoding
[
https://issues.apache.org/jira/browse/MESOS-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-4964:
--
Summary: curl based docker fetcher fails to decode chunked encoding (was:
curl fetcher fails to decode chunked encoding)
> curl based docker fetcher fails to decode chunked encoding
> --
>
> Key: MESOS-4964
> URL: https://issues.apache.org/jira/browse/MESOS-4964
> Project: Mesos
> Issue Type: Bug
> Components: fetcher
>Reporter: James Peach
> Labels: mesosphere
>
> If the curl-base fetcher gets a HTTP response that is chunked, the HTTP
> decode fails because the response says it is chunked, but curl is dechunking
> the body to stdout.
> {code}
> E0316 15:23:31.124482 13299 slave.cpp:3773] Container
> 'fa06a5ee-637e-480c-b602-59705b707d85' for executor 'jpeach.10489' of
> framework 96d1191b-cdf0-40f6-8840-e4d4d92a9345-0010 failed to start: Collect
> failed: Failed to decode HTTP responses: Decoding failed
> HTTP/1.1 400 Bad Request
> Server: nginx/1.9.4
> Date: Wed, 16 Mar 2016 22:23:30 GMT
> Content-Type: application/json
> Transfer-Encoding: chunked
> Connection: keep-alive
> X-Artifactory-Id: ae6c9bffd47ec19a:-61ef0a68:1537a605a05:-8000
> {
> "errors" : [ {
> "status" : 400,
> "message" : "Unsupported docker v2 repository request for
> 'docker-registry'"
> } ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4823) Implement port forwarding in `network/cni` isolator
[ https://issues.apache.org/jira/browse/MESOS-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15198135#comment-15198135 ] Dan Osborne edited comment on MESOS-4823 at 3/16/16 8:55 PM: - Thank you for providing the example use case. Can you explain, on a technical level, on what conditions you are planning to trigger creation of these ip-tables rules? I'm concerned that the capability you're trying to provide makes a lot of assumptions about both the mesos cluster and the CNI network's configurations, and to what degree both are accessible by the public network. I believe that if this behavior goes in, to some degree it should be opt-in or opt-out, as not all clusters nor CNI network's would want such a behavior. Some counter use cases - 1. if the CNI network _is_ assigning publicly accessible addresses, the port mapping becomes a redundant. 2. if they are using a load balancer, they would not need port forwarding as the load balancer will forward public requests onto the private CNI network. was (Author: djosborne): Thank you for providing the example use case. Can you explain, on a technical level, what condition you are planning that will trigger creation of these ip-tables rules? I'm concerned that the capability you're trying to provide makes a lot of assumptions about both the mesos cluster and the CNI network's configurations, and to what degree both are accessible by the public network. I believe that if this behavior goes in, to some degree it should be opt-in or opt-out, as not all clusters nor CNI network's would want such a behavior. Some counter use cases - 1. if the CNI network _is_ assigning publicly accessible addresses, the port mapping becomes a redundant. 2. if they are using a load balancer, they would not need port forwarding as the load balancer will forward public requests onto the private CNI network. > Implement port forwarding in `network/cni` isolator > --- > > Key: MESOS-4823 > URL: https://issues.apache.org/jira/browse/MESOS-4823 > Project: Mesos > Issue Type: Task > Components: containerization > Environment: linux >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan >Priority: Critical > Labels: mesosphere > > Most docker and appc images wish ports that micro-services are listening on, > to the outside world. When containers are running on bridged (or ptp) > networking this can be achieved by installing port forwarding rules on the > agent (using iptables). This can be done in the `network/cni` isolator. > The reason we would like this functionality to be implemented in the > `network/cni` isolator, and not a CNI plugin, is that the specifications > currently do not support specifying port forwarding rules. Further, to > install these rules the isolator needs two pieces of information, the exposed > ports and the IP address associated with the container. Bother are available > to the isolator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4976) Reject RESERVE on revocable resources
[
https://issues.apache.org/jira/browse/MESOS-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201199#comment-15201199
]
Klaus Ma commented on MESOS-4976:
-
Good point. I think it's not necessary.
> Reject RESERVE on revocable resources
> -
>
> Key: MESOS-4976
> URL: https://issues.apache.org/jira/browse/MESOS-4976
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Klaus Ma
>
> In {{Resources::apply}}, we did not check whether the resources is revocable
> or not. It does not make sense to reserve a revocable resources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4736) DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes fails on CentOS 6
[
https://issues.apache.org/jira/browse/MESOS-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-4736:
-
Sprint: (was: Mesosphere Sprint 31)
> DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes fails on
> CentOS 6
> -
>
> Key: MESOS-4736
> URL: https://issues.apache.org/jira/browse/MESOS-4736
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: Centos6 + GCC 4.9 on AWS
>Reporter: Joseph Wu
>Assignee: Joseph Wu
> Labels: flaky, mesosphere, test
>
> This test passes consistently on other OS's, but fails consistently on CentOS
> 6.
> Verbose logs from test failure:
> {code}
> [ RUN ] DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes
> I0222 18:16:12.327957 26681 leveldb.cpp:174] Opened db in 7.466102ms
> I0222 18:16:12.330528 26681 leveldb.cpp:181] Compacted db in 2.540139ms
> I0222 18:16:12.330580 26681 leveldb.cpp:196] Created db iterator in 16908ns
> I0222 18:16:12.330592 26681 leveldb.cpp:202] Seeked to beginning of db in
> 1403ns
> I0222 18:16:12.330600 26681 leveldb.cpp:271] Iterated through 0 keys in the
> db in 315ns
> I0222 18:16:12.330634 26681 replica.cpp:779] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0222 18:16:12.331082 26698 recover.cpp:447] Starting replica recovery
> I0222 18:16:12.331289 26698 recover.cpp:473] Replica is in EMPTY status
> I0222 18:16:12.332162 26703 replica.cpp:673] Replica in EMPTY status received
> a broadcasted recover request from (13761)@172.30.2.148:35274
> I0222 18:16:12.332701 26701 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I0222 18:16:12.333230 26699 recover.cpp:564] Updating replica status to
> STARTING
> I0222 18:16:12.334102 26698 master.cpp:376] Master
> 652149b4-3932-4d8b-ba6f-8c9d9045be70 (ip-172-30-2-148.mesosphere.io) started
> on 172.30.2.148:35274
> I0222 18:16:12.334116 26698 master.cpp:378] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/QEhLBS/credentials" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --http_authenticators="basic"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50"
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="100secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/QEhLBS/master"
> --zk_session_timeout="10secs"
> I0222 18:16:12.334354 26698 master.cpp:423] Master only allowing
> authenticated frameworks to register
> I0222 18:16:12.334363 26698 master.cpp:428] Master only allowing
> authenticated slaves to register
> I0222 18:16:12.334369 26698 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/QEhLBS/credentials'
> I0222 18:16:12.335366 26698 master.cpp:468] Using default 'crammd5'
> authenticator
> I0222 18:16:12.335492 26698 master.cpp:537] Using default 'basic' HTTP
> authenticator
> I0222 18:16:12.335623 26698 master.cpp:571] Authorization enabled
> I0222 18:16:12.335752 26703 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 2.314693ms
> I0222 18:16:12.335769 26700 whitelist_watcher.cpp:77] No whitelist given
> I0222 18:16:12.335778 26703 replica.cpp:320] Persisted replica status to
> STARTING
> I0222 18:16:12.335821 26697 hierarchical.cpp:144] Initialized hierarchical
> allocator process
> I0222 18:16:12.335965 26701 recover.cpp:473] Replica is in STARTING status
> I0222 18:16:12.336771 26703 replica.cpp:673] Replica in STARTING status
> received a broadcasted recover request from (13763)@172.30.2.148:35274
> I0222 18:16:12.337191 26696 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I0222 18:16:12.337635 26700 recover.cpp:564] Updating replica status to VOTING
> I0222 18:16:12.337671 26703 master.cpp:1712] The newly elected leader is
> master@172.30.2.148:35274 with id 652149b4-3932-4d8b-ba6f-8c9d9045be70
> I0222 18:16:12.337698 26703 master.cpp:1725] Elected as the leading master!
> I0222 18:16:12.337713 26703 master.cpp:1470] Recovering from registrar
> I0222 18:16:12.337828 26696 registrar.cpp:307] Recovering registrar
> I0222 18:16:12.339972 26702 leveldb.cpp:304] Persisting metadata (8
