[jira] [Commented] (MESOS-2376) Allow libprocess ip and port to be configured
[ https://issues.apache.org/jira/browse/MESOS-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689175#comment-15689175 ] Deshi Xiao commented on MESOS-2376: --- feel this issue is deprecated. prefer use REST API. does anyone can close it? > Allow libprocess ip and port to be configured > - > > Key: MESOS-2376 > URL: https://issues.apache.org/jira/browse/MESOS-2376 > Project: Mesos > Issue Type: Improvement > Components: java api >Reporter: Dario Rexin >Priority: Minor > > Currently if we want to configure the ip libprocess uses for communication, > we have to set the env var LIBPROCESS_IP, or LIBPROCESS_PORT for the port. > For the Java API this means, that the variable has to be set before the JVM > is started, because setting env vars from within JAVA is not possible / > non-trivial. Therefore it would be great to be able to pass them in to the > constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6625) Expose container id in ContainerStatus in DockerContainerizer.
[ https://issues.apache.org/jira/browse/MESOS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6625: -- Story Points: 2 > Expose container id in ContainerStatus in DockerContainerizer. > -- > > Key: MESOS-6625 > URL: https://issues.apache.org/jira/browse/MESOS-6625 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Jie Yu > Fix For: 1.2.0 > > > Currently, the container id is only exposed for MesosContainerizer. We should > make it consistent in DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6625) Expose container id in ContainerStatus in DockerContainerizer.
[ https://issues.apache.org/jira/browse/MESOS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689057#comment-15689057 ] Jie Yu commented on MESOS-6625: --- https://reviews.apache.org/r/54021/ > Expose container id in ContainerStatus in DockerContainerizer. > -- > > Key: MESOS-6625 > URL: https://issues.apache.org/jira/browse/MESOS-6625 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Jie Yu > > Currently, the container id is only exposed for MesosContainerizer. We should > make it consistent in DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6626) Support `foreachpair` for LinkedHashMap
[
https://issues.apache.org/jira/browse/MESOS-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Conway updated MESOS-6626:
---
Shepherd: Michael Park
Issue Type: Improvement (was: Bug)
> Support `foreachpair` for LinkedHashMap
> ---
>
> Key: MESOS-6626
> URL: https://issues.apache.org/jira/browse/MESOS-6626
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Neil Conway
>Assignee: Neil Conway
> Labels: mesosphere
>
> {{LinkedHashMap}} does not support iteration via {{foreachpair}}; it should.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5763) Task stuck in fetching is not cleaned up after --executor_registration_timeout.
[
https://issues.apache.org/jira/browse/MESOS-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5763:
--
Target Version/s: (was: 0.28.3)
Fix Version/s: 0.28.3
Backport for 0.28.x branch
{noformat}
commit 52a0b0a41482da35dc736ec2fd445b6099e7a4e7
Author: Anand Mazumdar
Date: Tue Nov 22 20:38:43 2016 -0800
Added MESOS-5763 to 0.28.3 CHANGELOG.
commit 2d61bde81e3d6fb7400ec5f7078ceedd8d2bb802
Author: Jiang Yan Xu
Date: Fri Jul 1 18:12:01 2016 -0700
Made Mesos containerizer error messages more consistent.
We've been using slightly different wordings of the same condition in
multiple places in Mesos containerizer but they don't provide
additional information about where this failure is thrown in a long
continuation chain. Since failures don't capture the location in the
code we'd better distinguish them in a more meaningful way to assist
debugging.
Review: https://reviews.apache.org/r/49653
commit d7f8b8558974ee8739d460d53faf54a52832b754
Author: Jiang Yan Xu
Date: Fri Jul 1 18:11:29 2016 -0700
Improved Mesos containerizer invariant checking.
One of the reasons for MESOS-5763 is due to the lack invariant
checking. Mesos containerizer transitions the container state in
particular ways so when continuation chains could potentially be
interleaved with other actions we should verify the state transitions.
Review: https://reviews.apache.org/r/49652
commit 008e04433026aaec49779197c4a7b6655d5bb693
Author: Jiang Yan Xu
Date: Fri Jul 1 15:25:54 2016 -0700
Improved Mesos containerizer logging and documentation.
Review: https://reviews.apache.org/r/49651
commit 90b5be8e95c5868ea9142625b97050a75d0664f5
Author: Jiang Yan Xu
Date: Wed Jul 6 13:48:34 2016 -0700
Fail container launch if it's destroyed during logger->prepare().
Review: https://reviews.apache.org/r/49725
commit 56b4c561e08a8cc36e5cbc3a786981412bf226dd
Author: Jiang Yan Xu
Date: Fri Jul 1 15:27:37 2016 -0700
Fixed Mesos containerizer to set container FETCHING state.
If the container state is not properly set to FETCHING, Mesos agent
cannot detect the terminated executor when the fetcher times out.
Review: https://reviews.apache.org/r/49650
{noformat}
> Task stuck in fetching is not cleaned up after
> --executor_registration_timeout.
> ---
>
> Key: MESOS-5763
> URL: https://issues.apache.org/jira/browse/MESOS-5763
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 0.28.0, 1.0.0
>Reporter: Yan Xu
>Assignee: Yan Xu
>Priority: Blocker
> Fix For: 0.28.3, 1.0.0
>
>
> When the fetching process hangs forever due to reasons such as HDFS issues,
> Mesos containerizer would attempt to destroy the container and kill the
> executor after {{--executor_registration_timeout}}. However this reliably
> fails for us: the executor would be killed by the launcher destroy and the
> container would be destroyed but the agent would never find out that the
> executor is terminated thus leaving the task in the STAGING state forever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6335) Add user doc for task group tasks
[ https://issues.apache.org/jira/browse/MESOS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688873#comment-15688873 ] Gilbert Song commented on MESOS-6335: - It targets for 1.2.0 now. > Add user doc for task group tasks > - > > Key: MESOS-6335 > URL: https://issues.apache.org/jira/browse/MESOS-6335 > Project: Mesos > Issue Type: Documentation >Reporter: Vinod Kone >Assignee: Gilbert Song > > Committed some basic documentation. So moving this to pods-improvements epic > and targeting this for 1.2.0. I would like this to track the more > comprehensive documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6631) Disallow frameworks from modifying FrameworkInfo.roles.
[
https://issues.apache.org/jira/browse/MESOS-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-6631:
---
Description:
In "phase 1" of the multi-role framework support, we want to preserve the
existing behavior of single-role framework support in that we disallow
frameworks from modifying their role.
With multi-role framework support, we will initially disallow frameworks from
modifying the roles field. We will treat {{FrameworkInfo.roles}} as a set
rather than a list, so ordering does not matter for equality.
One difference between {{role}} and {{roles}} is that for {{role}}
modification, we ignore it. But, with {{roles}} modification, since this is a
new feature, we can disallow it by rejecting the framework subscription.
Later, in phase 2, we will allow frameworks to modify their roles, see
MESOS-6627.
was:
In "phase 1" of the multi-role framework support, we want to preserve the
existing behavior of single-role framework support in that we disallow
frameworks from modifying their role.
With multi-role framework support, we will initially disallow frameworks from
modifying the roles field. We will treat {{FrameworkInfo.roles}} as a set
rather than a list, so ordering does not matter for equality.
Later, in phase 2, we will allow frameworks to modify their roles, see
MESOS-6627.
> Disallow frameworks from modifying FrameworkInfo.roles.
> ---
>
> Key: MESOS-6631
> URL: https://issues.apache.org/jira/browse/MESOS-6631
> Project: Mesos
> Issue Type: Task
> Components: master
>Reporter: Benjamin Mahler
>
> In "phase 1" of the multi-role framework support, we want to preserve the
> existing behavior of single-role framework support in that we disallow
> frameworks from modifying their role.
> With multi-role framework support, we will initially disallow frameworks from
> modifying the roles field. We will treat {{FrameworkInfo.roles}} as a set
> rather than a list, so ordering does not matter for equality.
> One difference between {{role}} and {{roles}} is that for {{role}}
> modification, we ignore it. But, with {{roles}} modification, since this is a
> new feature, we can disallow it by rejecting the framework subscription.
> Later, in phase 2, we will allow frameworks to modify their roles, see
> MESOS-6627.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6628) Add a FrameworkInfo.roles field along with a MULTI_ROLE capability.
[
https://issues.apache.org/jira/browse/MESOS-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-6628:
---
Description:
In order to support frameworks having multiple roles, we will introduce a
{{FrameworkInfo.roles}} field as a {{repeated string}}.
Note that because we cannot distinguish between an empty set of {{roles}}
(new-style framework wanting no roles) and an unset {{role}} (old-style
framework wanting the "*" role), we must introduce a framework capability (i.e.
MULTI_ROLE). This capability will be required for a framework to use the new
{{roles}} field.
{code}
message FrameworkInfo {
...
// Roles are the entities to which allocations are made.
// The framework must have at least one role in order to
// be offered resources. Note that `role` is deprecated
// in favor of `roles` and only one of these fields must
// be used. Since we cannot distinguish between empty
// `roles` and the default unset `role`, we require that
// frameworks set the `MULTI_ROLE` capability if
// setting the `roles` field.
optional string role = 6 [default="*", deprecated=true];
repeated string roles = 12;
...
}
{code}
Validation will be added in MESOS-6629 and we will prevent roles from being
modified in MESOS-6631.
was:
In order to support frameworks having multiple roles, we will introduce a
{{FrameworkInfo.roles}} field as a {{repeated string}}.
Note that because we cannot distinguish between an empty set of {{roles}}
(new-style framework wanting no roles) and an unset {{role}} (old-style
framework wanting the "*" role), we must introduce a framework capability (i.e.
MULTI_ROLE). This capability will be required for a framework to use the new
{{roles}} field.
{code}
message FrameworkInfo {
...
// Roles are the entities to which allocations are made.
// The framework must have at least one role in order to
// be offered resources. Note that `role` is deprecated
// in favor of `roles` and only one of these fields must
// be used. Since we cannot distinguish between empty
// `roles` and the default unset `role`, we require that
// frameworks set the `MULTI_ROLE` capability if
// setting the `roles` field.
optional string role = 6 [default="*", deprecated=true];
repeated string roles = 12;
...
}
{code}
> Add a FrameworkInfo.roles field along with a MULTI_ROLE capability.
> ---
>
> Key: MESOS-6628
> URL: https://issues.apache.org/jira/browse/MESOS-6628
> Project: Mesos
> Issue Type: Task
> Components: framework api
>Reporter: Benjamin Mahler
>
> In order to support frameworks having multiple roles, we will introduce a
> {{FrameworkInfo.roles}} field as a {{repeated string}}.
> Note that because we cannot distinguish between an empty set of {{roles}}
> (new-style framework wanting no roles) and an unset {{role}} (old-style
> framework wanting the "*" role), we must introduce a framework capability
> (i.e. MULTI_ROLE). This capability will be required for a framework to use
> the new {{roles}} field.
> {code}
> message FrameworkInfo {
> ...
> // Roles are the entities to which allocations are made.
> // The framework must have at least one role in order to
> // be offered resources. Note that `role` is deprecated
> // in favor of `roles` and only one of these fields must
> // be used. Since we cannot distinguish between empty
> // `roles` and the default unset `role`, we require that
> // frameworks set the `MULTI_ROLE` capability if
> // setting the `roles` field.
> optional string role = 6 [default="*", deprecated=true];
> repeated string roles = 12;
> ...
> }
> {code}
> Validation will be added in MESOS-6629 and we will prevent roles from being
> modified in MESOS-6631.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6631) Disallow frameworks from modifying FrameworkInfo.roles.
Benjamin Mahler created MESOS-6631:
--
Summary: Disallow frameworks from modifying FrameworkInfo.roles.
Key: MESOS-6631
URL: https://issues.apache.org/jira/browse/MESOS-6631
Project: Mesos
Issue Type: Task
Components: master
Reporter: Benjamin Mahler
In "phase 1" of the multi-role framework support, we want to preserve the
existing behavior of single-role framework support in that we disallow
frameworks from modifying their role.
With multi-role framework support, we will initially disallow frameworks from
modifying the roles field. We will treat {{FrameworkInfo.roles}} as a set
rather than a list, so ordering does not matter for equality.
Later, in phase 2, we will allow frameworks to modify their roles, see
MESOS-6627.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6629) Add master validation of FrameworkInfo.roles.
[
https://issues.apache.org/jira/browse/MESOS-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-6629:
---
Description:
The master should disallow frameworks from subscribing based on the following:
(1) Only one of {{FrameworkInfo.role}} and {{FrameworkInfo.roles}} must be set
at a time.
(2) If {{FrameworkInfo.roles}} is set, then the MULTI_ROLE framework capability
must be provided.
(3) If the MULTI_ROLE framework capability is provided, then
{{FrameworkInfo.role}} must not be set.
(4) {{FrameworkInfo.roles}} must not contain duplicate entries.
was:
The master should disallow frameworks from subscribing based on the following:
(1) Only one of {{FrameworkInfo.role}} and {{FrameworkInfo.roles}} must be set
at a time.
(2) If {{FrameworkInfo.roles}} is set, then the MULTI_ROLE framework capability
must be provided.
(3) If the MULTI_ROLE framework capability is provided, then
{{FrameworkInfo.role}} must not be set.
> Add master validation of FrameworkInfo.roles.
> -
>
> Key: MESOS-6629
> URL: https://issues.apache.org/jira/browse/MESOS-6629
> Project: Mesos
> Issue Type: Task
> Components: master
>Reporter: Benjamin Mahler
>
> The master should disallow frameworks from subscribing based on the following:
> (1) Only one of {{FrameworkInfo.role}} and {{FrameworkInfo.roles}} must be
> set at a time.
> (2) If {{FrameworkInfo.roles}} is set, then the MULTI_ROLE framework
> capability must be provided.
> (3) If the MULTI_ROLE framework capability is provided, then
> {{FrameworkInfo.role}} must not be set.
> (4) {{FrameworkInfo.roles}} must not contain duplicate entries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6630) Add some benchmark test for quota allocation
Guangya Liu created MESOS-6630: -- Summary: Add some benchmark test for quota allocation Key: MESOS-6630 URL: https://issues.apache.org/jira/browse/MESOS-6630 Project: Mesos Issue Type: Bug Reporter: Guangya Liu After made a minor update for allocator performance here https://reviews.apache.org/r/53929/ , I found that we have no benchmark test for quota allocation, we should add some benchmark test for such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6629) Add master validation of FrameworkInfo.roles.
Benjamin Mahler created MESOS-6629:
--
Summary: Add master validation of FrameworkInfo.roles.
Key: MESOS-6629
URL: https://issues.apache.org/jira/browse/MESOS-6629
Project: Mesos
Issue Type: Task
Components: master
Reporter: Benjamin Mahler
The master should disallow frameworks from subscribing based on the following:
(1) Only one of {{FrameworkInfo.role}} and {{FrameworkInfo.roles}} must be set
at a time.
(2) If {{FrameworkInfo.roles}} is set, then the MULTI_ROLE framework capability
must be provided.
(3) If the MULTI_ROLE framework capability is provided, then
{{FrameworkInfo.role}} must not be set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6628) Add a FrameworkInfo.roles field along with a MULTI_ROLE capability.
[
https://issues.apache.org/jira/browse/MESOS-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-6628:
---
Description:
In order to support frameworks having multiple roles, we will introduce a
{{FrameworkInfo.roles}} field as a {{repeated string}}.
Note that because we cannot distinguish between an empty set of {{roles}}
(new-style framework wanting no roles) and an unset {{role}} (old-style
framework wanting the "*" role), we must introduce a framework capability (i.e.
MULTI_ROLE). This capability will be required for a framework to use the new
{{roles}} field.
{code}
message FrameworkInfo {
...
// Roles are the entities to which allocations are made.
// The framework must have at least one role in order to
// be offered resources. Note that `role` is deprecated
// in favor of `roles` and only one of these fields must
// be used. Since we cannot distinguish between empty
// `roles` and the default unset `role`, we require that
// frameworks set the `MULTI_ROLE` capability if
// setting the `roles` field.
optional string role = 6 [default="*", deprecated=true];
repeated string roles = 12;
...
}
{code}
was:
In order to support frameworks having multiple roles, we will introduce a
{{FrameworkInfo.roles}} field as a {{repeated string}}.
Note that because we cannot distinguish between an empty set of {{roles}}
(new-style framework wanting no roles) and an unset {{role}} (old-style
framework wanting the "*" role), we must introduce a framework capability (i.e.
MULTI_ROLE). This capability will be required for a framework to use the new
{{roles}} field.
> Add a FrameworkInfo.roles field along with a MULTI_ROLE capability.
> ---
>
> Key: MESOS-6628
> URL: https://issues.apache.org/jira/browse/MESOS-6628
> Project: Mesos
> Issue Type: Task
> Components: framework api
>Reporter: Benjamin Mahler
>
> In order to support frameworks having multiple roles, we will introduce a
> {{FrameworkInfo.roles}} field as a {{repeated string}}.
> Note that because we cannot distinguish between an empty set of {{roles}}
> (new-style framework wanting no roles) and an unset {{role}} (old-style
> framework wanting the "*" role), we must introduce a framework capability
> (i.e. MULTI_ROLE). This capability will be required for a framework to use
> the new {{roles}} field.
> {code}
> message FrameworkInfo {
> ...
> // Roles are the entities to which allocations are made.
> // The framework must have at least one role in order to
> // be offered resources. Note that `role` is deprecated
> // in favor of `roles` and only one of these fields must
> // be used. Since we cannot distinguish between empty
> // `roles` and the default unset `role`, we require that
> // frameworks set the `MULTI_ROLE` capability if
> // setting the `roles` field.
> optional string role = 6 [default="*", deprecated=true];
> repeated string roles = 12;
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6628) Add a FrameworkInfo.roles field along with a MULTI_ROLE capability.
Benjamin Mahler created MESOS-6628:
--
Summary: Add a FrameworkInfo.roles field along with a MULTI_ROLE
capability.
Key: MESOS-6628
URL: https://issues.apache.org/jira/browse/MESOS-6628
Project: Mesos
Issue Type: Task
Components: framework api
Reporter: Benjamin Mahler
In order to support frameworks having multiple roles, we will introduce a
{{FrameworkInfo.roles}} field as a {{repeated string}}.
Note that because we cannot distinguish between an empty set of {{roles}}
(new-style framework wanting no roles) and an unset {{role}} (old-style
framework wanting the "*" role), we must introduce a framework capability (i.e.
MULTI_ROLE). This capability will be required for a framework to use the new
{{roles}} field.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6621) SSL downgrade path will CHECK-fail when using both temporary and persistent sockets
[
https://issues.apache.org/jira/browse/MESOS-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-6621:
-
Fix Version/s: 1.0.3
1.1.1
0.28.3
> SSL downgrade path will CHECK-fail when using both temporary and persistent
> sockets
> ---
>
> Key: MESOS-6621
> URL: https://issues.apache.org/jira/browse/MESOS-6621
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Affects Versions: 0.28.2, 1.0.2, 1.1.0
> Environment: SSL with downgrade enabled
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>Priority: Blocker
> Labels: mesosphere
> Fix For: 0.28.3, 1.1.1, 1.2.0, 1.0.3
>
> Attachments: test.patch, test_linkee.cpp
>
>
> The code path for downgrading sockets from SSL to non-SSL includes this code:
> {code}
> // If this address is a temporary link.
> if (temps.count(addresses[to_fd]) > 0) {
> temps[addresses[to_fd]] = to_fd;
> // No need to erase as we're changing the value, not the key.
> }
> // If this address is a persistent link.
> if (persists.count(addresses[to_fd]) > 0) {
> persists[addresses[to_fd]] = to_fd;
> // No need to erase as we're changing the value, not the key.
> }
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L2311-L2321
> It is possible for libprocess to hold both temporary and persistent sockets
> to the same address. This can happen when a message is first sent
> ({{ProcessBase::send}}), and then a link is established
> ({{ProcessBase::link}}). When the target of the message/link is a non-SSL
> socket, both temporary and persistent sockets go through the downgrade path.
> If a temporary socket is present while a persistent socket is being created,
> the above code will remap both temporary and persistent sockets to the same
> address (it should only remap the persistent socket). This leads to some
> CHECK failures if those sockets are used or closed later:
> * {code}
> bool persist = persists.count(address) > 0;
> bool temp = temps.count(address) > 0;
> if (persist || temp) {
> int s = persist ? persists[address] : temps[address];
> CHECK(sockets.count(s) > 0);
> socket = sockets.at(s);
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L1942
> * {code}
> if (dispose.count(s) > 0) {
> // This is either a temporary socket we created or it's a
> // socket that we were receiving data from and possibly
> // sending HTTP responses back on. Clean up either way.
> if (addresses.count(s) > 0) {
> const Address& address = addresses[s];
> CHECK(temps.count(address) > 0 && temps[address] == s);
> temps.erase(address);
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L2044
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6621) SSL downgrade path will CHECK-fail when using both temporary and persistent sockets
[
https://issues.apache.org/jira/browse/MESOS-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688513#comment-15688513
]
Joseph Wu commented on MESOS-6621:
--
{code:title=0.28.3}
commit 95ee5a583eef1e60ba743900d49629b2286dbc97
Author: Joseph Wu
Date: Tue Nov 22 17:08:42 2016 -0800
Added MESOS-6621 to CHANGELOG for 0.28.3.
commit 4c56f51f5ea8b633cee12cbc212f29a760f99583
Author: Joseph Wu
Date: Tue Nov 22 17:07:40 2016 -0800
Fix SSL downgrade pathway for temporary/persistent sockets.
{code}
{code:title=1.0.3}
commit c82a283d87af557128a96ec02f2ef9a00f00d4df
Author: Joseph Wu
Date: Tue Nov 22 17:06:59 2016 -0800
Added MESOS-6621 to CHANGELOG for 1.0.3.
commit 3c5b5e054c0328dc500d4940d527d40bb1526b65
Author: Joseph Wu
Date: Tue Nov 22 17:03:02 2016 -0800
Fix SSL downgrade pathway for temporary/persistent sockets.
{code}
{code:title=1.1.1}
commit de3a1b58a105493e45e87299bcaf3a4279939a02
Author: Joseph Wu
Date: Tue Nov 22 16:58:56 2016 -0800
Added MESOS-6621 to CHANGELOG for 1.1.1.
commit 1d84b0b42d0cd067c034091a4897e817fc2f86d0
Author: Joseph Wu
Date: Tue Nov 22 17:00:01 2016 -0800
Fix SSL downgrade pathway for temporary/persistent sockets.
{code}
> SSL downgrade path will CHECK-fail when using both temporary and persistent
> sockets
> ---
>
> Key: MESOS-6621
> URL: https://issues.apache.org/jira/browse/MESOS-6621
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Affects Versions: 0.28.2, 1.0.2, 1.1.0
> Environment: SSL with downgrade enabled
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>Priority: Blocker
> Labels: mesosphere
> Fix For: 1.2.0
>
> Attachments: test.patch, test_linkee.cpp
>
>
> The code path for downgrading sockets from SSL to non-SSL includes this code:
> {code}
> // If this address is a temporary link.
> if (temps.count(addresses[to_fd]) > 0) {
> temps[addresses[to_fd]] = to_fd;
> // No need to erase as we're changing the value, not the key.
> }
> // If this address is a persistent link.
> if (persists.count(addresses[to_fd]) > 0) {
> persists[addresses[to_fd]] = to_fd;
> // No need to erase as we're changing the value, not the key.
> }
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L2311-L2321
> It is possible for libprocess to hold both temporary and persistent sockets
> to the same address. This can happen when a message is first sent
> ({{ProcessBase::send}}), and then a link is established
> ({{ProcessBase::link}}). When the target of the message/link is a non-SSL
> socket, both temporary and persistent sockets go through the downgrade path.
> If a temporary socket is present while a persistent socket is being created,
> the above code will remap both temporary and persistent sockets to the same
> address (it should only remap the persistent socket). This leads to some
> CHECK failures if those sockets are used or closed later:
> * {code}
> bool persist = persists.count(address) > 0;
> bool temp = temps.count(address) > 0;
> if (persist || temp) {
> int s = persist ? persists[address] : temps[address];
> CHECK(sockets.count(s) > 0);
> socket = sockets.at(s);
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L1942
> * {code}
> if (dispose.count(s) > 0) {
> // This is either a temporary socket we created or it's a
> // socket that we were receiving data from and possibly
> // sending HTTP responses back on. Clean up either way.
> if (addresses.count(s) > 0) {
> const Address& address = addresses[s];
> CHECK(temps.count(address) > 0 && temps[address] == s);
> temps.erase(address);
> {code}
> https://github.com/apache/mesos/blob/1.1.x/3rdparty/libprocess/src/process.cpp#L2044
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1763) Add support for frameworks to receive resources for multiple roles.
[ https://issues.apache.org/jira/browse/MESOS-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-1763: --- Epic Name: multi-role frameworks (phase 1) (was: multi-role frameworks) > Add support for frameworks to receive resources for multiple roles. > --- > > Key: MESOS-1763 > URL: https://issues.apache.org/jira/browse/MESOS-1763 > Project: Mesos > Issue Type: Epic > Components: allocation, framework api, master >Reporter: Vinod Kone >Assignee: Benjamin Mahler > Labels: mesosphere, multi-tenancy > > Currently, a framework can only obtain resources for a single allocation > role. This design discusses allowing frameworks to obtain resources for > multiple allocation roles. > Use cases: > * Allow an instance of a framework to be “multi-tenant” (e.g. Marathon, > Aurora, etc). Currently, users run multiple instances of a framework under > different roles to support multiple tenants. > * Allow a framework to further leverage the resource allocation primitives > within Mesos to ensure it has sufficient resource guarantees in place (e.g. a > framework may want to set different guarantees amongst the tasks it needs to > run, without necessarily being multi-tenant). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6627) Allow frameworks to modify the role(s) they are subscribed to.
[ https://issues.apache.org/jira/browse/MESOS-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-6627: --- Epic Name: multi-role frameworks (phase 2) (was: Modify framework roles.) > Allow frameworks to modify the role(s) they are subscribed to. > -- > > Key: MESOS-6627 > URL: https://issues.apache.org/jira/browse/MESOS-6627 > Project: Mesos > Issue Type: Epic > Components: framework api, master >Reporter: Benjamin Mahler > > Currently, we do not provide the ability for frameworks to change the roles > they are subscribed with. As we begin to support "multi-tenant" frameworks > (i.e. multi-role support in MESOS-1763), it will become necessary to allow > frameworks to add and remove roles as "tenants" come and go from the > framework. > Because of this being necessary to support multi-role frameworks, this is > considered "phase 2" of the multi-role framework project. See the design > published in MESOS-4284. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5966) Add libprocess HTTP tests with SSL support
[
https://issues.apache.org/jira/browse/MESOS-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688426#comment-15688426
]
Joseph Wu commented on MESOS-5966:
--
Some independently committed cleanup:
{code}
commit e1c90722fa3c206a42000ced602dfdf4e7932141
Author: Greg Mann
Date: Tue Nov 22 13:44:59 2016 -0800
Added missing cleanup to libprocess 'finalize()'.
The `finalize()` function in libprocess previously did
not delete the thread-local `Executor` which is used to
defer execution to an unspecified context. This object
must be deleted during finalization so that the
`__executor__` macro creates a new process if libprocess
is subsequently reinitialized (and to not leak the pointer).
Review: https://reviews.apache.org/r/53817/
{code}
{code}
commit 5efc83f4937d6b03e66995fa15be01f63fd24fb1
Author: Greg Mann
Date: Tue Nov 22 13:46:06 2016 -0800
Moved server socket deletion in 'process::finalize()'.
We need to destroy the server socket and discard its
future before we finalize the process manager
because the socket's `onDiscard` callback may need to
run in the event loop (such as for libevent sockets), but
process manager finalization stops the event loop.
Review: https://reviews.apache.org/r/53975/
{code}
> Add libprocess HTTP tests with SSL support
> --
>
> Key: MESOS-5966
> URL: https://issues.apache.org/jira/browse/MESOS-5966
> Project: Mesos
> Issue Type: Task
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: mesosphere
>
> Libprocess contains SSL unit tests which test our SSL support using simple
> sockets. We should add tests which also make use of libprocess's various HTTP
> classes and helpers in a variety of SSL configurations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3094) Mesos on Windows
[
https://issues.apache.org/jira/browse/MESOS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-3094:
-
Comment: was deleted
(was: {code}
commit 88c22daec2b048f35fd9b273872babe64a51dbf7
Author: Alex Clemmer
Date: Tue Nov 22 11:55:17 2016 -0800
Windows: Disable persistent state for Windows master.
Many Mesos tests use the master in some form. Of those, relatively few
strictly require the LevelDB-based storage for the replicated log.
(Only tests with master failover require persistent storage.)
Since we cannot currently compile LevelDB on Windows, and because
running Mesos tests on Windows involves compiling and running the
master, this commit will remove the direct dependency on the LevelDB
storage for Windows builds of the master.
Review: https://reviews.apache.org/r/53313/
{code})
> Mesos on Windows
>
>
> Key: MESOS-3094
> URL: https://issues.apache.org/jira/browse/MESOS-3094
> Project: Mesos
> Issue Type: Epic
> Components: containerization, libprocess, stout
>Reporter: Joseph Wu
>Assignee: Alex Clemmer
> Labels: mesosphere
>
> The ultimate goal of this is to have all containerizer tests running and
> passing on Windows Server.
> # It must build (see MESOS-898).
> # All OS-specific code (that is touched by the containerizer) must be ported
> to Windows.
> # The containizer itself must be ported to Windows, alongside the
> MesosContainerizer.
> Note: Isolation (cgroups) will probably not exist on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5932) Replicated log's dependency on leveldb prevents it from being used on Windows
[
https://issues.apache.org/jira/browse/MESOS-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688420#comment-15688420
]
Joseph Wu commented on MESOS-5932:
--
{code}
commit 88c22daec2b048f35fd9b273872babe64a51dbf7
Author: Alex Clemmer
Date: Tue Nov 22 11:55:17 2016 -0800
Windows: Disable persistent state for Windows master.
Many Mesos tests use the master in some form. Of those, relatively few
strictly require the LevelDB-based storage for the replicated log.
(Only tests with master failover require persistent storage.)
Since we cannot currently compile LevelDB on Windows, and because
running Mesos tests on Windows involves compiling and running the
master, this commit will remove the direct dependency on the LevelDB
storage for Windows builds of the master.
Review: https://reviews.apache.org/r/53313/
{code}
> Replicated log's dependency on leveldb prevents it from being used on Windows
> -
>
> Key: MESOS-5932
> URL: https://issues.apache.org/jira/browse/MESOS-5932
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
> Labels: agent, master, mesosphere
>
> The replicated log (in src/log/) depends on leveldb to store and persist data
> in the replicas.
> This dependency is well-contained within replica.cpp, but until it is
> abstracted out, it nonetheless prevents the master from being built on
> Windows, which in turn prevents the agent tests from being built and run on
> Windows.
> Preliminary investigation shows that we will probably want to split this work
> into 2 parts:
> * Temporarily remove the ability of the master to use the replicated log on
> Windows (in master/main.cpp). This should involve 1 conditional where we
> instantiate a `Log::Log`. This should be enough for us to light up the agent
> tests.
> * Add leveldb Windows support to Mesos. This involves: adding CMake files to
> build leveldb source, and adding Windows-specific `port_*` files that will
> map the platform-specific constructs of leveldb to Windows. We can take hints
> from leveldown and other projects, which add their own `port_*` files that
> suit their purposes (namely, running leveldb, in node, on Windows). NOTE: the
> leveldb community explicitly calls out in its documentation that it is not
> interested in non-POSIX changes, so it is likely that this will never be
> inducted into the mainline leveldb codebase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3094) Mesos on Windows
[
https://issues.apache.org/jira/browse/MESOS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688418#comment-15688418
]
Joseph Wu commented on MESOS-3094:
--
{code}
commit 88c22daec2b048f35fd9b273872babe64a51dbf7
Author: Alex Clemmer
Date: Tue Nov 22 11:55:17 2016 -0800
Windows: Disable persistent state for Windows master.
Many Mesos tests use the master in some form. Of those, relatively few
strictly require the LevelDB-based storage for the replicated log.
(Only tests with master failover require persistent storage.)
Since we cannot currently compile LevelDB on Windows, and because
running Mesos tests on Windows involves compiling and running the
master, this commit will remove the direct dependency on the LevelDB
storage for Windows builds of the master.
Review: https://reviews.apache.org/r/53313/
{code}
> Mesos on Windows
>
>
> Key: MESOS-3094
> URL: https://issues.apache.org/jira/browse/MESOS-3094
> Project: Mesos
> Issue Type: Epic
> Components: containerization, libprocess, stout
>Reporter: Joseph Wu
>Assignee: Alex Clemmer
> Labels: mesosphere
>
> The ultimate goal of this is to have all containerizer tests running and
> passing on Windows Server.
> # It must build (see MESOS-898).
> # All OS-specific code (that is touched by the containerizer) must be ported
> to Windows.
> # The containizer itself must be ported to Windows, alongside the
> MesosContainerizer.
> Note: Isolation (cgroups) will probably not exist on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6626) Support `foreachpair` for LinkedHashMap
Neil Conway created MESOS-6626:
--
Summary: Support `foreachpair` for LinkedHashMap
Key: MESOS-6626
URL: https://issues.apache.org/jira/browse/MESOS-6626
Project: Mesos
Issue Type: Bug
Components: stout
Reporter: Neil Conway
Assignee: Neil Conway
{{LinkedHashMap}} does not support iteration via {{foreachpair}}; it should.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6379) Updated webui to material style
[ https://issues.apache.org/jira/browse/MESOS-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688175#comment-15688175 ] Benjamin Mahler commented on MESOS-6379: Is it possible to switch to the blue top bar and add the logo, without making the other style changes? > Updated webui to material style > --- > > Key: MESOS-6379 > URL: https://issues.apache.org/jira/browse/MESOS-6379 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: haosdent >Assignee: haosdent > Labels: web > Attachments: material_style.gif > > > Refer to [material style guideline | https://material.google.com/] After > some simple hacks, I found it should not too hard to update current WebUI to > material style. > We could use this library > https://github.com/FezVrasta/bootstrap-material-design . Its license is MIT > license which compatible with Apache 2.0, and same with the library Bootstrap > which has already used in Mesos. > Document: > https://docs.google.com/document/d/12JVUq-_zAUwvzz46KJVYgpfhRCx-TiH_ajfZG5KrutE/edit?usp=sharing > The following screenshot is the result after some changes in current WebUI. > !material_style.gif|width=800! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6379) Updated webui to material style
[ https://issues.apache.org/jira/browse/MESOS-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688075#comment-15688075 ] John Ashenden commented on MESOS-6379: -- I think this is a great idea. I'd urge caution at over-stylizing the interface though. > Updated webui to material style > --- > > Key: MESOS-6379 > URL: https://issues.apache.org/jira/browse/MESOS-6379 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: haosdent >Assignee: haosdent > Labels: web > Attachments: material_style.gif > > > Refer to [material style guideline | https://material.google.com/] After > some simple hacks, I found it should not too hard to update current WebUI to > material style. > We could use this library > https://github.com/FezVrasta/bootstrap-material-design . Its license is MIT > license which compatible with Apache 2.0, and same with the library Bootstrap > which has already used in Mesos. > Document: > https://docs.google.com/document/d/12JVUq-_zAUwvzz46KJVYgpfhRCx-TiH_ajfZG5KrutE/edit?usp=sharing > The following screenshot is the result after some changes in current WebUI. > !material_style.gif|width=800! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6396) Hooks should allow sandbox dependent environment variables.
[
https://issues.apache.org/jira/browse/MESOS-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687775#comment-15687775
]
Till Toenshoff commented on MESOS-6396:
---
Turns out that this fact is not just confusing and a problem for my specific
needs, it actually likely is a bug, hence I am now going to propose a simple
fix for that.
> Hooks should allow sandbox dependent environment variables.
> ---
>
> Key: MESOS-6396
> URL: https://issues.apache.org/jira/browse/MESOS-6396
> Project: Mesos
> Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
> Labels: containerizer, docker, hooks, module
>
> The {{slaveExecutorEnvironmentDecorator}} hook is the only one that allows
> mutating the executor environment of a Docker container. That callback has no
> means of getting the location of the sandbox. That in turn means that it is
> not possible for a hook to create files and respective environment variables
> listing paths within the sandbox for the executor to access.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6396) Hooks should allow sandbox dependent environment variables.
[
https://issues.apache.org/jira/browse/MESOS-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687772#comment-15687772
]
Till Toenshoff commented on MESOS-6396:
---
As discussed directly, it seems we will need to do a bit of substantial
refactoring to get this covered neatly. Specifically the fact that the volumes
are taken from the {{ContainerInfo}} in {{src/docker/docker.cpp}} while most
other things are actually being stored and operated on via {{Container}} makes
this a bit more involved. We may want to change these things, move all the jazz
we see in
https://github.com/apache/mesos/blob/master/src/docker/docker.cpp#L558-L632 out
and up into the population of {{Container}}.
Without such refactor, we would have to mutate {{ContainerInfo}} rather late
for that hook and stuff it back into {{Container}} which appears to be a likely
source of bugs.
> Hooks should allow sandbox dependent environment variables.
> ---
>
> Key: MESOS-6396
> URL: https://issues.apache.org/jira/browse/MESOS-6396
> Project: Mesos
> Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
> Labels: containerizer, docker, hooks, module
>
> The {{slaveExecutorEnvironmentDecorator}} hook is the only one that allows
> mutating the executor environment of a Docker container. That callback has no
> means of getting the location of the sandbox. That in turn means that it is
> not possible for a hook to create files and respective environment variables
> listing paths within the sandbox for the executor to access.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6625) Expose container id in ContainerStatus in DockerContainerizer.
[ https://issues.apache.org/jira/browse/MESOS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-6625: -- Sprint: Mesosphere Sprint 47 > Expose container id in ContainerStatus in DockerContainerizer. > -- > > Key: MESOS-6625 > URL: https://issues.apache.org/jira/browse/MESOS-6625 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Jie Yu > > Currently, the container id is only exposed for MesosContainerizer. We should > make it consistent in DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6625) Expose container id in ContainerStatus in DockerContainerizer.
Jie Yu created MESOS-6625: - Summary: Expose container id in ContainerStatus in DockerContainerizer. Key: MESOS-6625 URL: https://issues.apache.org/jira/browse/MESOS-6625 Project: Mesos Issue Type: Bug Reporter: Jie Yu Currently, the container id is only exposed for MesosContainerizer. We should make it consistent in DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-6625) Expose container id in ContainerStatus in DockerContainerizer.
[ https://issues.apache.org/jira/browse/MESOS-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu reassigned MESOS-6625: - Assignee: Jie Yu > Expose container id in ContainerStatus in DockerContainerizer. > -- > > Key: MESOS-6625 > URL: https://issues.apache.org/jira/browse/MESOS-6625 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Jie Yu > > Currently, the container id is only exposed for MesosContainerizer. We should > make it consistent in DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687422#comment-15687422
]
Greg Mann edited comment on MESOS-5658 at 11/22/16 6:25 PM:
Part of this ticket was addressed as part of MESOS-5966.
The following reviews add a {{how}} parameter to {{Socket::shutdown}}:
https://reviews.apache.org/r/53990/
https://reviews.apache.org/r/53804/
A TODO was also added to consider changing/removing the default shutdown mode.
was (Author: greggomann):
Part of this ticket was addressed as part of MESOS-5966.
The following review adds a {{how}} parameter to {{Socket::shutdown}}:
https://reviews.apache.org/r/53804/
A TODO was also added to consider changing/removing the default shutdown mode.
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3753) Test the HTTP Scheduler library with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15416149#comment-15416149 ] Greg Mann edited comment on MESOS-3753 at 11/22/16 6:24 PM: The following patches parametrize a scheduler test to run in both SSL enabled and disabled configurations, by making use of libprocess reinitialization code. https://reviews.apache.org/r/50969/ https://reviews.apache.org/r/50857/ https://reviews.apache.org/r/53990/ https://reviews.apache.org/r/53804/ https://reviews.apache.org/r/53805/ Note that more comprehensive libprocess-level tests of SSL behavior can be found in MESOS-5966 was (Author: greggomann): The following patches parametrize a scheduler test to run in both SSL enabled and disabled configurations, by making use of libprocess reinitialization code. https://reviews.apache.org/r/50969/ https://reviews.apache.org/r/50857/ https://reviews.apache.org/r/53804/ https://reviews.apache.org/r/53805/ Note that more comprehensive libprocess-level tests of SSL behavior can be found in MESOS-5966 > Test the HTTP Scheduler library with SSL enabled > > > Key: MESOS-3753 > URL: https://issues.apache.org/jira/browse/MESOS-3753 > Project: Mesos > Issue Type: Story > Components: framework, HTTP API, test >Reporter: Joseph Wu >Assignee: Greg Mann > Labels: mesosphere, security > > Currently, the HTTP Scheduler library does not support SSL-enabled Mesos. > (You can manually test this by spinning up an SSL-enabled master and attempt > to run the event-call framework example against it.) > We need to add tests that check the HTTP Scheduler library against > SSL-enabled Mesos: > * with downgrade support, > * with required framework/client-side certifications, > * with/without verification of certificates (master-side), > * with/without verification of certificates (framework-side), > * with a custom certificate authority (CA) > These options should be controlled by the same environment variables found on > the [SSL user doc|http://mesos.apache.org/documentation/latest/ssl/]. > Note: This issue will be broken down into smaller sub-issues as bugs/problems > are discovered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-5658:
-
Assignee: (was: Greg Mann)
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-5658:
-
Sprint: (was: Mesosphere Sprint 47)
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687422#comment-15687422
]
Greg Mann edited comment on MESOS-5658 at 11/22/16 6:00 PM:
Part of this ticket was addressed as part of MESOS-5966.
The following review adds a {{how}} parameter to {{Socket::shutdown}}:
https://reviews.apache.org/r/53804/
A TODO was also added to consider changing/removing the default shutdown mode.
was (Author: greggomann):
This ticket was addressed as part of MESOS-5966.
The following review adds a {{how}} parameter to {{Socket::shutdown}}:
https://reviews.apache.org/r/53804/
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687422#comment-15687422
]
Greg Mann commented on MESOS-5658:
--
This ticket was addressed as part of MESOS-5966.
The following review adds a {{how}} parameter to {{Socket::shutdown}}:
https://reviews.apache.org/r/53804/
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-5658:
-
Sprint: Mesosphere Sprint 47
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5658) Socket::shutdown() is inconsistent with BSD sockets API
[
https://issues.apache.org/jira/browse/MESOS-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann reassigned MESOS-5658:
Assignee: Greg Mann
> Socket::shutdown() is inconsistent with BSD sockets API
> ---
>
> Key: MESOS-5658
> URL: https://issues.apache.org/jira/browse/MESOS-5658
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
>
> In libprocess, the {{Socket::shutdown()}} member function is inconsistent
> with the {{shutdown(2)}} function from the Berkeley sockets API: the former
> doesn't take any parameters (and implicitly *only* shuts down the
> receiver-side of the socket), whereas the latter takes a parameter that
> controls which side(s) are shutdown.
> IMO we should either make these behave the same or document why they are
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5900) Support Unix domain socket connections in libprocess
[ https://issues.apache.org/jira/browse/MESOS-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15686645#comment-15686645 ] Ilya Pronin commented on MESOS-5900: Is anyone working on this? I'd like to help. Can I take it? > Support Unix domain socket connections in libprocess > > > Key: MESOS-5900 > URL: https://issues.apache.org/jira/browse/MESOS-5900 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Neil Conway >Assignee: Benjamin Hindman > Labels: mesosphere > > We should consider allowing two programs on the same host using libprocess to > communicate via Unix domain sockets rather than TCP. This has a few > advantages: > * Security: remote hosts cannot connect to the Unix socket. Domain sockets > also offer additional support for > [authentication|https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/sect-Defensive_Coding-Authentication-UNIX_Domain.html]. > * Performance: domain sockets are marginally faster than localhost TCP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6624) Master web interface does not work on Firefox 45 (angular js issue)
[
https://issues.apache.org/jira/browse/MESOS-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15686643#comment-15686643
]
Adam Cecile commented on MESOS-6624:
Still happening here, I can help if needed:
{quote}
acecile@HI-LIN-3RPRRY1:~$ apt-cache policy firefox-esr
firefox-esr:
Installed: 45.4.0esr-1~deb8u2
Candidate: 45.5.0esr-1~deb8u1
Version table:
45.5.0esr-1~deb8u1 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
*** 45.4.0esr-1~deb8u2 0
100 /var/lib/dpkg/status
45.3.0esr-1~deb8u1 0
500 http://ftp.fr.debian.org/debian/ jessie/main amd64 Packages
{quote}
> Master web interface does not work on Firefox 45 (angular js issue)
> ---
>
> Key: MESOS-6624
> URL: https://issues.apache.org/jira/browse/MESOS-6624
> Project: Mesos
> Issue Type: Bug
> Components: webui
>Affects Versions: 1.1.0
>Reporter: Adam Cecile
>Assignee: haosdent
>
> Hello,
> I only see the "No master leading" message which is obvisouly wrong because
> the API just work as expected. Switching to another browser make it works
> again.
> In Firefox console I can see the following error:
> {quote}
> SyntaxError: in strict mode code, functions may be declared only at top level
> or immediately within another function controllers.js:845:19
> "Error: [ng:areq]
> http://errors.angularjs.org/1.2.3/ng/areq?p0=MainCntl=not%20a%20function%2C%20got%20undefined
> A/<@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:6:449
> tb@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:18:250
> Oa@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:18:337
> hd/this.$gethttp://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:62:96
> Q/<@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:49:117
> q@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:7:359
> Q@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:48:1
> f@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:43:24
> f@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:43:1
> f@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:43:1
> y/<@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:42:180
> Xb/c/http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:17:455
> xd/this.$gethttp://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:101:35
> xd/this.$gethttp://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:101:312
> Xb/c/<@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:17:413
> d@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:30:328
> Xb/c@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:17:321
> Xb@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:18:30
> Rc@http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:17:99
> @http://zelda.service.domain.com:5050/static/js/angular-1.2.3.min.js:199:1
> f.Callbacks/n@http://zelda.service.domain.com:5050/static/js/jquery-1.7.1.min.js:2:14779
> f.Callbacks/o.fireWith@http://zelda.service.domain.com:5050/static/js/jquery-1.7.1.min.js:2:15553
> fhttp://zelda.service.domain.com:5050/static/js/jquery-1.7.1.min.js:2:9771
> fhttp://zelda.service.domain.com:5050/static/js/jquery-1.7.1.min.js:2:14346
> "
> {quote}
> It used to work just fine with 1.0.x and I think it matters because Firefox
> 45 is Debian stable browser so there's plenty of users.
> Best regards, Adam.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
