[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213234#comment-15213234
]
Yong Tang commented on MESOS-4112:
--
[~mcypark], thanks for the review.
I updated the usage of macros to replace EQ(true and EQ(false with
..._TRUE/_FALSE. The review request is below:
https://reviews.apache.org/r/45356/
I also added the HTTP response related macros (counterpart of existing macros)
with the review request:
https://reviews.apache.org/r/45357/
Please let me know if there are any issues. Again, thanks for the review!
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4943) Reduce the size of LinuxRootfs in tests.
[ https://issues.apache.org/jira/browse/MESOS-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-4943: -- Labels: mesosphere (was: ) Component/s: containerization > Reduce the size of LinuxRootfs in tests. > > > Key: MESOS-4943 > URL: https://issues.apache.org/jira/browse/MESOS-4943 > Project: Mesos > Issue Type: Improvement > Components: containerization >Reporter: Jie Yu > Labels: mesosphere > > Right now, LinuxRootfs copies files from the host filesystem to construct a > chroot-able rootfs. We copy a lot of unnecessary files, making it very large. > We can potentially strip a lot files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5044) Temporary directories created by environment->mkdtemp cleanup can be problematic.
Gilbert Song created MESOS-5044: --- Summary: Temporary directories created by environment->mkdtemp cleanup can be problematic. Key: MESOS-5044 URL: https://issues.apache.org/jira/browse/MESOS-5044 Project: Mesos Issue Type: Improvement Components: test Reporter: Gilbert Song Currently in mesos test, we have the temporary directories created by `environment->mkdtemp()` cleaned up until the end of the test suite, which can be problematic. For instance, if we have many tests in a test suite, each of those tests is performing large size disk read/write in its temp dir, which may lead to out of disk issue on some resource limited machines. We should have these temp dir created by `environment->mkdtemp` cleaned up during each test teardown. Currently we only clean up the sandbox for each test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3243) Replace NULL with nullptr
[
https://issues.apache.org/jira/browse/MESOS-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213150#comment-15213150
]
Michael Park commented on MESOS-3243:
-
It seems that {{clang-tidy}} was able to replace a {{0}} to {{nullptr}} in an
appropriate call-site.
Were you able to characterize the places where {{clang-tidy}} did not replace
{{NULL}} to {{nullptr}}?
That is, perhaps we were passing {{NULL}} incorrectly to a function takes an
{{int}}?
> Replace NULL with nullptr
> -
>
> Key: MESOS-3243
> URL: https://issues.apache.org/jira/browse/MESOS-3243
> Project: Mesos
> Issue Type: Improvement
>Reporter: Michael Park
>Assignee: Tomasz Janiszewski
>
> As part of the C++ upgrade, it would be nice to move our use of {{NULL}} over
> to use {{nullptr}}. I think it would be an interesting exercise to do this
> with {{clang-modernize}} using the [nullptr
> transform|http://clang.llvm.org/extra/UseNullptrTransform.html] (although
> it's probably just as easy to use {{sed}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213140#comment-15213140
]
Michael Park commented on MESOS-4112:
-
[~yongtang] Thanks for the patch! I've committed it. Could you follow up with a
patch to use the versions that we added?
We should be able to find all of the instances of them by grepping for
{{EQ(true}} and {{EQ(false}}.
Regarding (3) and (4), I think we should do (3) but leave (4) as-is for now.
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213134#comment-15213134
]
Michael Park commented on MESOS-4112:
-
{noformat}
commit f978d3ce97ec22fc6f4e52a41ff8e22616c76d55
Author: Yong Tang
Date: Sat Mar 26 13:37:07 2016 -0400
Cleaned up libprocess gtest macros.
1. `AWAIT_EQ_FOR` have be added for completeness.
2. Missing equivalents of `EXPECT_TRUE`/`EXPECT_FALSE` have been added:
- `AWAIT_ASSERT_TRUE_FOR`
- `AWAIT_ASSERT_TRUE`
- `AWAIT_ASSERT_FALSE_FOR`
- `AWAIT_ASSERT_FALSE`
- `AWAIT_EXPECT_TRUE_FOR`
- `AWAIT_EXPECT_FALSE_FOR`
Review: https://reviews.apache.org/r/45070/
{noformat}
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5041) Add cgroups unified isolator
[ https://issues.apache.org/jira/browse/MESOS-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213036#comment-15213036 ] haosdent edited comment on MESOS-5041 at 3/26/16 4:28 PM: -- Patch: |Add cgroups unified isolator. | https://reviews.apache.org/r/45085/ | |Enable cgroups unified isolator in isolation. | https://reviews.apache.org/r/45086/ | was (Author: haosd...@gmail.com): Patch: |Add cgroup unified isolator. | https://reviews.apache.org/r/45085/ | |Enable cgroups unified isolator in isolation. | https://reviews.apache.org/r/45086/ | > Add cgroups unified isolator > > > Key: MESOS-5041 > URL: https://issues.apache.org/jira/browse/MESOS-5041 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: haosdent >Assignee: haosdent > > Implement the cgroups unified isolator and enable it in Mesos containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5043) Add cpuacct subsystem support in cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213038#comment-15213038
]
haosdent edited comment on MESOS-5043 at 3/26/16 4:27 PM:
--
Patch:
| Add `CpuacctSubsystem` for cgroups unified isolator. |
https://reviews.apache.org/r/45352/ |
| Migrate test cases for `cpuacct` subsystem to cgroups unified isolator. |
https://reviews.apache.org/r/45353/ |
| Migrate `UserCgroupIsolatorTest` to cgroups unified isolator. |
https://reviews.apache.org/r/45354/ |
was (Author: haosd...@gmail.com):
Patch:
Add `CpuacctSubsystem` for cgroups unified isolator.
https://reviews.apache.org/r/45352/
Migrate test cases for `cpuacct` subsystem to cgroups unified isolator.
https://reviews.apache.org/r/45353/
Migrate `UserCgroupIsolatorTest` to cgroups unified isolator.
https://reviews.apache.org/r/45354/
> Add cpuacct subsystem support in cgroups unified isolator
> -
>
> Key: MESOS-5043
> URL: https://issues.apache.org/jira/browse/MESOS-5043
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> Add cgroups cpuacct subsystem support in cgroups unified isolator. And we
> need to port the test cases of {{CgroupsCpushareIsolatorProcess}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5042) Add cpu subsystem support in cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213037#comment-15213037
]
haosdent edited comment on MESOS-5042 at 3/26/16 4:27 PM:
--
Patch:
| Add `CpuSubsystem` for cgroups unified isolator. |
https://reviews.apache.org/r/45087/ |
| Migrate test cases for `cpu` subsystem to cgroups unified isolator. |
https://reviews.apache.org/r/45351/ |
was (Author: haosd...@gmail.com):
Patch:
Add `CpuSubsystem` for cgroups unified isolator.
https://reviews.apache.org/r/45087/
Migrate test cases for `cpu` subsystem to cgroups unified isolator.
https://reviews.apache.org/r/45351/
> Add cpu subsystem support in cgroups unified isolator
> -
>
> Key: MESOS-5042
> URL: https://issues.apache.org/jira/browse/MESOS-5042
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> Add cgroups cpu subsystem support in cgroups unified isolator. And we need to
> port the test cases of {{CgroupsCpushareIsolatorProcess}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5041) Add cgroups unified isolator
[ https://issues.apache.org/jira/browse/MESOS-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213036#comment-15213036 ] haosdent edited comment on MESOS-5041 at 3/26/16 4:26 PM: -- Patch: |Add cgroup unified isolator. | https://reviews.apache.org/r/45085/ | |Enable cgroups unified isolator in isolation. | https://reviews.apache.org/r/45086/ | was (Author: haosd...@gmail.com): Patch: Add cgroup unified isolator. https://reviews.apache.org/r/45085/ Enable cgroups unified isolator in isolation. https://reviews.apache.org/r/45086/ > Add cgroups unified isolator > > > Key: MESOS-5041 > URL: https://issues.apache.org/jira/browse/MESOS-5041 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: haosdent >Assignee: haosdent > > Implement the cgroups unified isolator and enable it in Mesos containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5043) Add cpuacct subsystem support in cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5043:
Description: Add cgroups cpuacct subsystem support in cgroups unified
isolator. And we need to port the test cases of
{{CgroupsCpushareIsolatorProcess}} as well.
Issue Type: Task (was: Improvement)
> Add cpuacct subsystem support in cgroups unified isolator
> -
>
> Key: MESOS-5043
> URL: https://issues.apache.org/jira/browse/MESOS-5043
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> Add cgroups cpuacct subsystem support in cgroups unified isolator. And we
> need to port the test cases of {{CgroupsCpushareIsolatorProcess}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5042) Add cpu subsystem support in cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5042:
Description: Add cgroups cpu subsystem support in cgroups unified isolator.
And we need to port the test cases of {{CgroupsCpushareIsolatorProcess}} as
well.
Issue Type: Task (was: Improvement)
> Add cpu subsystem support in cgroups unified isolator
> -
>
> Key: MESOS-5042
> URL: https://issues.apache.org/jira/browse/MESOS-5042
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> Add cgroups cpu subsystem support in cgroups unified isolator. And we need to
> port the test cases of {{CgroupsCpushareIsolatorProcess}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5041) Add cgroups unified isolator
[ https://issues.apache.org/jira/browse/MESOS-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-5041: Description: Implement the cgroups unified isolator and enable it in Mesos containerizer. Issue Type: Task (was: Improvement) Summary: Add cgroups unified isolator (was: Add cgroup unified isolator) > Add cgroups unified isolator > > > Key: MESOS-5041 > URL: https://issues.apache.org/jira/browse/MESOS-5041 > Project: Mesos > Issue Type: Task > Components: isolation >Reporter: haosdent >Assignee: haosdent > > Implement the cgroups unified isolator and enable it in Mesos containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5040) Add cgroups_subsystems flag for cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5040:
Description: In past, we specify the cgroups subsystems we used in Mesos
containerizer in {{--isolation}} flag. In cgroups unified isolator, we need to
add this separate flag to control which subsystems we enable.
Issue Type: Task (was: Improvement)
> Add cgroups_subsystems flag for cgroups unified isolator
>
>
> Key: MESOS-5040
> URL: https://issues.apache.org/jira/browse/MESOS-5040
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> In past, we specify the cgroups subsystems we used in Mesos containerizer in
> {{--isolation}} flag. In cgroups unified isolator, we need to add this
> separate flag to control which subsystems we enable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5039) Add Subsystem abstraction for cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5039:
Issue Type: Task (was: Improvement)
> Add Subsystem abstraction for cgroups unified isolator
> --
>
> Key: MESOS-5039
> URL: https://issues.apache.org/jira/browse/MESOS-5039
> Project: Mesos
> Issue Type: Task
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> In cgroups unified isolator, we introduce {{Subsystem}} abstraction as the
> base class of other cgroups subsystem implementation classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5039) Add Subsystem abstraction for cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5039:
Description: In cgroups unified isolator, we introduce {{Subsystem}}
abstraction as the base class of other cgroups subsystem implementation classes.
> Add Subsystem abstraction for cgroups unified isolator
> --
>
> Key: MESOS-5039
> URL: https://issues.apache.org/jira/browse/MESOS-5039
> Project: Mesos
> Issue Type: Improvement
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
> In cgroups unified isolator, we introduce {{Subsystem}} abstraction as the
> base class of other cgroups subsystem implementation classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5038) Added a any mechanism for futures
[
https://issues.apache.org/jira/browse/MESOS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5038:
Summary: Added a any mechanism for futures (was: Added a any mechanism for
futures.)
> Added a any mechanism for futures
> -
>
> Key: MESOS-5038
> URL: https://issues.apache.org/jira/browse/MESOS-5038
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: haosdent
>Assignee: haosdent
>
> Now we already have {{collect}} and {{await}} mechanisms which would wait for
> a list of {{Future}}. However, we would like to return immediately if any of
> the list of {{Future}} complete instead of wait for the whole list finished
> in {{collect}}. The interface of this any mechanism could be
> {code}
> template
> Future any(const std::list>& futures);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5043) Add cpuacct subsystem support in cgroups unified isolator
haosdent created MESOS-5043: --- Summary: Add cpuacct subsystem support in cgroups unified isolator Key: MESOS-5043 URL: https://issues.apache.org/jira/browse/MESOS-5043 Project: Mesos Issue Type: Improvement Components: isolation Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5042) Add cpu subsystem support in cgroups unified isolator
haosdent created MESOS-5042: --- Summary: Add cpu subsystem support in cgroups unified isolator Key: MESOS-5042 URL: https://issues.apache.org/jira/browse/MESOS-5042 Project: Mesos Issue Type: Improvement Components: isolation Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5040) Add cgroups_subsystems flag for cgroups unified isolator
haosdent created MESOS-5040: --- Summary: Add cgroups_subsystems flag for cgroups unified isolator Key: MESOS-5040 URL: https://issues.apache.org/jira/browse/MESOS-5040 Project: Mesos Issue Type: Improvement Components: isolation Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5041) Add cgroup unified isolator
haosdent created MESOS-5041: --- Summary: Add cgroup unified isolator Key: MESOS-5041 URL: https://issues.apache.org/jira/browse/MESOS-5041 Project: Mesos Issue Type: Improvement Components: isolation Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5039) Add Subsystem abstraction for cgroups unified isolator
haosdent created MESOS-5039:
---
Summary: Add Subsystem abstraction for cgroups unified isolator
Key: MESOS-5039
URL: https://issues.apache.org/jira/browse/MESOS-5039
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: haosdent
Assignee: haosdent
Now we already have {{collect}} and {{await}} mechanisms which would wait for a
list of {{Future}}. However, we would like to return immediately if any of the
list of {{Future}} complete instead of wait for the whole list finished in
{{collect}}. The interface of this any mechanism could be
{code}
template
Future any(const std::list>& futures);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5039) Add Subsystem abstraction for cgroups unified isolator
[
https://issues.apache.org/jira/browse/MESOS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5039:
Description: (was: Now we already have {{collect}} and {{await}}
mechanisms which would wait for a list of {{Future}}. However, we would like to
return immediately if any of the list of {{Future}} complete instead of wait
for the whole list finished in {{collect}}. The interface of this any mechanism
could be
{code}
template
Future any(const std::list>& futures);
{code}
)
Component/s: (was: libprocess)
isolation
> Add Subsystem abstraction for cgroups unified isolator
> --
>
> Key: MESOS-5039
> URL: https://issues.apache.org/jira/browse/MESOS-5039
> Project: Mesos
> Issue Type: Improvement
> Components: isolation
>Reporter: haosdent
>Assignee: haosdent
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5038) Added a any mechanism for futures.
haosdent created MESOS-5038:
---
Summary: Added a any mechanism for futures.
Key: MESOS-5038
URL: https://issues.apache.org/jira/browse/MESOS-5038
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: haosdent
Assignee: haosdent
Now we already have {{collect}} and {{await}} mechanisms which would wait for a
list of {{Future}}. However, we would like to return immediately if any of the
list of {{Future}} complete instead of wait for the whole list finished in
{{collect}}. The interface of this any mechanism could be
{code}
template
Future any(const std::list>& futures);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5037) foreachkey behaviour is not expected in multimap
[
https://issues.apache.org/jira/browse/MESOS-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5037:
Labels: stout (was: )
> foreachkey behaviour is not expected in multimap
>
>
> Key: MESOS-5037
> URL: https://issues.apache.org/jira/browse/MESOS-5037
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: haosdent
> Labels: stout
>
> Currently the {{foreachkey}} implementation is
> {code}
> #define foreachkey(VAR, COL)\
> foreachpair (VAR, __foreach__::ignore, COL)
> {code}
> This works in most structures. But in multimap, one key may map to multi
> values. This means there are multi pairs which have same key. So when call
> {{foreachkey}}, the {{key}} would duplicated when iteration. My idea to solve
> this is we prefer call {{foreach}} on {{(COL).keys()}} if {{keys()}} method
> exists in {{COL}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5037) foreachkey behaviour is not expected in multimap
[
https://issues.apache.org/jira/browse/MESOS-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-5037:
Component/s: stout
> foreachkey behaviour is not expected in multimap
>
>
> Key: MESOS-5037
> URL: https://issues.apache.org/jira/browse/MESOS-5037
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: haosdent
> Labels: stout
>
> Currently the {{foreachkey}} implementation is
> {code}
> #define foreachkey(VAR, COL)\
> foreachpair (VAR, __foreach__::ignore, COL)
> {code}
> This works in most structures. But in multimap, one key may map to multi
> values. This means there are multi pairs which have same key. So when call
> {{foreachkey}}, the {{key}} would duplicated when iteration. My idea to solve
> this is we prefer call {{foreach}} on {{(COL).keys()}} if {{keys()}} method
> exists in {{COL}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5037) foreachkey behaviour is not expected in multimap
haosdent created MESOS-5037:
---
Summary: foreachkey behaviour is not expected in multimap
Key: MESOS-5037
URL: https://issues.apache.org/jira/browse/MESOS-5037
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Currently the {{foreachkey}} implementation is
{code}
#define foreachkey(VAR, COL)\
foreachpair (VAR, __foreach__::ignore, COL)
{code}
This works in most structures. But in multimap, one key may map to multi
values. This means there are multi pairs which have same key. So when call
{{foreachkey}}, the {{key}} would duplicated when iteration. My idea to solve
this is we prefer call {{foreach}} on {{(COL).keys()}} if {{keys()}} method
exists in {{COL}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5027) Enable authenticated login in the webui
[
https://issues.apache.org/jira/browse/MESOS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-5027:
--
Fix Version/s: 0.29.0
> Enable authenticated login in the webui
> ---
>
> Key: MESOS-5027
> URL: https://issues.apache.org/jira/browse/MESOS-5027
> Project: Mesos
> Issue Type: Improvement
> Components: master, security, webui
>Reporter: Greg Mann
> Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> The webui hits a number of endpoints to get the data that it displays:
> {{/state}}, {{/metrics/snapshot}}, {{/files/browse}}, {{/files/read}}, and
> maybe others? Once authentication is enabled on these endpoints, we need to
> add a login prompt to the webui so that users can provide credentials.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5036) Executor shutdown grace period does not have an upper bound.
Alexander Rukletsov created MESOS-5036:
--
Summary: Executor shutdown grace period does not have an upper
bound.
Key: MESOS-5036
URL: https://issues.apache.org/jira/browse/MESOS-5036
Project: Mesos
Issue Type: Improvement
Reporter: Alexander Rukletsov
MESOS-4949 enables frameworks to set the executor's shutdown grace period to a
custom value. This value has to be non-negative, but there are no restrictions
for the upper bound.
We should consider introducing a flag specifying the maximum executor shutdown
grace period (can be on the master or on the agent) and a check that either
adjusts the shutdown grace period in {{ExecutorInfo}} or rejects the launch
task request altogether.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
