[jira] [Commented] (MESOS-721) No man pages and devel documentation in build
[ https://issues.apache.org/jira/browse/MESOS-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147695#comment-14147695 ] Timothy St. Clair commented on MESOS-721: - Typical installation of system software creates man pages which are helpful to both developers and administrators alike. Ideally it would be nice if Mesos were to create man-pages for it's executables and configuration settings. No man pages and devel documentation in build - Key: MESOS-721 URL: https://issues.apache.org/jira/browse/MESOS-721 Project: Mesos Issue Type: Bug Components: documentation Affects Versions: 0.15.0 Reporter: Timothy St. Clair There are no man pages documentation that are generated and installed as part of the build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1832) Slave should accept PingSlaveMessage but not PING message.
Vinod Kone created MESOS-1832: - Summary: Slave should accept PingSlaveMessage but not PING message. Key: MESOS-1832 URL: https://issues.apache.org/jira/browse/MESOS-1832 Project: Mesos Issue Type: Task Reporter: Vinod Kone Slave handles both PING message and PingSlaveMessage in until 0.22.0 for backwards compatibility (https://reviews.apache.org/r/25867/). In 0.23.0, slave no longer needs handle PING. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1330) Introduce connection/transport abstraction to stout
[ https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14148274#comment-14148274 ] Vinod Kone commented on MESOS-1330: --- Great. Thanks for doing this. Introduce connection/transport abstraction to stout --- Key: MESOS-1330 URL: https://issues.apache.org/jira/browse/MESOS-1330 Project: Mesos Issue Type: Improvement Components: general, libprocess Reporter: Niklas Quarfot Nielsen Labels: libprocess, network I think it makes sense to think in terms of different low or middle layer transports (which can accommodate channels like SSL). We could capture connection life-cycles and network send/receive primitives in a much explicit manner than currently in libprocess. I have a proof of concept transport / connection abstraction ready and which we can use to iterate a design. Notably, there are opportunities to change the current SocketManager/Socket abstractions to explicit ConnectionManager/Connection, which allow several and composeable communication layers. I am proposing to own this ticket and am looking for a shepherd to (thoroughly) go over design considerations before jumping into an actual implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1461) Add task reconciliation to the Python API.
[ https://issues.apache.org/jira/browse/MESOS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reassigned MESOS-1461: -- Assignee: Niklas Quarfot Nielsen Add task reconciliation to the Python API. -- Key: MESOS-1461 URL: https://issues.apache.org/jira/browse/MESOS-1461 Project: Mesos Issue Type: Task Components: python api Affects Versions: 0.19.0 Reporter: Benjamin Mahler Assignee: Niklas Quarfot Nielsen Looks like the 'reconcileTasks' call was added to the C++ and Java APIs but was never added to the Python API. This may be obviated by the lower level API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1461) Add task reconciliation to the Python API.
[
https://issues.apache.org/jira/browse/MESOS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14148364#comment-14148364
]
Benjamin Mahler commented on MESOS-1461:
{noformat}
commit f1da58fb22b28afd65313f6801b35bce436199ab
Author: Niklas Nielsen n...@qni.dk
Date: Thu Sep 25 14:12:12 2014 -0700
Added reconcileTasks to python scheduler.
The last step of wiring up reconcileTasks in the python bindings.
Review: https://reviews.apache.org/r/25986
{noformat}
Add task reconciliation to the Python API.
--
Key: MESOS-1461
URL: https://issues.apache.org/jira/browse/MESOS-1461
Project: Mesos
Issue Type: Task
Components: python api
Affects Versions: 0.19.0
Reporter: Benjamin Mahler
Assignee: Niklas Quarfot Nielsen
Fix For: 0.21.0
Looks like the 'reconcileTasks' call was added to the C++ and Java APIs but
was never added to the Python API.
This may be obviated by the lower level API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-1833) Running docker container with colon in executor id generates error
Elizabeth Lingg created MESOS-1833: -- Summary: Running docker container with colon in executor id generates error Key: MESOS-1833 URL: https://issues.apache.org/jira/browse/MESOS-1833 Project: Mesos Issue Type: Bug Components: containerization Affects Versions: 0.21.0 Environment: ubuntu (mesosphere vangrant vm) Reporter: Elizabeth Lingg Fix For: 0.20.1 I created and launched a container successfully in chronos, but when mesos ran the docker container, docker did not accept the volumes setting due to the colon in the executor id (-v option). Here is the executor id, which is valid: ct:141167016:0:lldocker. In mesos, there will be a fix to avoid using the host directory by use of a simlink and mapping. However, ideally docker will fix this issue. They should accept executor ids with colons as the format is valid. Here is the error log: Error: One iContainer '8fdb0cd7-86f8-4bc9-bd1b-d36f86663bb3' for executor 'ct:141167016:0:lldocker' of framework '20140925-174859-16842879-5050-1573-' failed to start: Failed to 'docker run -d -c 512 -m 536870912 -e mesos_task_id=ct:141167016:0:lldocker -e CHRONOS_JOB_OWNER= -e MESOS_SANDBOX=/mnt/mesos/sandbox -v /tmp/mesos/slaves/20140925-181954-16842879-5050-1560-0/frameworks/20140925-174859-16842879-5050-1573-/executors/ct:141167016:0:lldocker/runs/8fdb0cd7-86f8-4bc9-bd1b-d36f86663bb3:/mnt/mesos/sandbox --net host --entrypoint /bin/sh --name mesos-8fdb0cd7-86f8-4bc9-bd1b-d36f86663bb3 libmesos/ubuntu -c while sleep 10; do date =u %T; done': exit status = exited with status 2 stderr = invalid value /tmp/mesos/slaves/20140925-181954-16842879-5050-1560-0/frameworks/20140925-174859-16842879-5050-1573-/executors/ct:141167016:0:lldocker/runs/8fdb0cd7-86f8-4bc9-bd1b-d36f86663bb3:/mnt/mesos/sandbox for flag -v: bad format for volumes: /tmp/mesos/slaves/20140925-181954-16842879-5050-1560-0/frameworks/20140925-174859-16842879-5050-1573-/executors/ct:141167016:0:lldocker/runs/8fdb0cd7-86f8-4bc9-bd1b-d36f86663bb3:/mnt/mesos/sandbox -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MESOS-1389) Reconciliation can send TASK_LOST before a terminal update reaches the framework.
[ https://issues.apache.org/jira/browse/MESOS-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler resolved MESOS-1389. Resolution: Fixed Assignee: Benjamin Mahler Resolved via MESOS-1410. Reconciliation can send TASK_LOST before a terminal update reaches the framework. - Key: MESOS-1389 URL: https://issues.apache.org/jira/browse/MESOS-1389 Project: Mesos Issue Type: Bug Affects Versions: 0.19.0 Reporter: Benjamin Mahler Assignee: Benjamin Mahler Fix For: 0.21.0 There's an unfortunate case with reconciliation, where we end up sending TASK_LOST first and then the slave sends the valid terminal status update. When the slave re-registers with terminal tasks that have un-acked updates. The master does not store these tasks. So while the slave still needs to send the terminal status updates, the master will reply with TASK_LOST for reconciliation. We may need to ensure that all status update acknowledgements go through the master to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1330) Introduce connection/transport abstraction to stout
[ https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14148458#comment-14148458 ] Niklas Quarfot Nielsen commented on MESOS-1330: --- [~tstclair] [~bmahler] [~vi...@twitter.com] I would love your input on the approach/abstraction before moving forward. Joris work cut process.cpp in half (!) and it just let us contain, tool around and instrument libev and experiment with different transports libevent, asio, libuv. Or for example speed things up with off-loading I/O in various ways pin to CPU / accelerate with kernel modules etc. The API in the proof-of-concept can be found here: https://github.com/mesosphere/mesos/blob/abstract-event-manager/3rdparty/libprocess/src/event_manager.hpp#L13 It is still a bit rough, but we will follow up with more docs on the different calls and where/how it is used. Introduce connection/transport abstraction to stout --- Key: MESOS-1330 URL: https://issues.apache.org/jira/browse/MESOS-1330 Project: Mesos Issue Type: Improvement Components: general, libprocess Reporter: Niklas Quarfot Nielsen Labels: libprocess, network I think it makes sense to think in terms of different low or middle layer transports (which can accommodate channels like SSL). We could capture connection life-cycles and network send/receive primitives in a much explicit manner than currently in libprocess. I have a proof of concept transport / connection abstraction ready and which we can use to iterate a design. Notably, there are opportunities to change the current SocketManager/Socket abstractions to explicit ConnectionManager/Connection, which allow several and composeable communication layers. I am proposing to own this ticket and am looking for a shepherd to (thoroughly) go over design considerations before jumping into an actual implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-986) Add versioning to messages.
[
https://issues.apache.org/jira/browse/MESOS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-986:
--
Description:
Message versioning in Mesos provides a number of benefits:
# Prevent incompatible version combinations. For example, we want to reject
slaves that are 1 version behind the master.
# The biggest win is providing the ability to determine behavior based on the
cross-component versioning. For example, in MESOS-1668 we wanted the master to
send a different ping message based on the version of the slave. In MESOS-1696,
we wanted to perform reconciliation in the master based on the version of the
slave. In both cases, when we don't have the version, we have to either rely on
hacks/tricks, or add additional phases.
was:
We currently do not prevent rogue versions of components from communicating
within the cluster. Adding versioning to our messages will allow us to enforce
version compatibility.
We would need to figure out the right semantics for each pair of components
that communicate with each other.
For example, if an old incompatible Slave attempts to register with a Master,
the Master can either ignore it, or shut it down.
Summary: Add versioning to messages. (was: Add versioning to messages
to prevent communication across incompatible versions of components.)
cc [~benjaminhindman]
[~vinodkone] and I chatted about an approach to add versioning at the
libprocess layer.
We could add the ability for an application to initialize libprocess with the
application version. This gets encoded via a special libprocess HTTP header.
{{install}} handlers can optionally receive a {{Version}}, akin to how they can
optionally receive the sender UPID currently.
Add versioning to messages.
---
Key: MESOS-986
URL: https://issues.apache.org/jira/browse/MESOS-986
Project: Mesos
Issue Type: Improvement
Reporter: Benjamin Mahler
Message versioning in Mesos provides a number of benefits:
# Prevent incompatible version combinations. For example, we want to reject
slaves that are 1 version behind the master.
# The biggest win is providing the ability to determine behavior based on the
cross-component versioning. For example, in MESOS-1668 we wanted the master
to send a different ping message based on the version of the slave. In
MESOS-1696, we wanted to perform reconciliation in the master based on the
version of the slave. In both cases, when we don't have the version, we have
to either rely on hacks/tricks, or add additional phases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-986) Add versioning to messages.
[ https://issues.apache.org/jira/browse/MESOS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-986: -- Description: Message versioning in Mesos provides a number of benefits: (1) Prevent incompatible version combinations. For example, we want to reject slaves that are 1 version behind the master. (2) The biggest win is providing the ability to determine behavior based on the cross-component versioning. For example, in MESOS-1668 we wanted the master to send a different ping message based on the version of the slave. In MESOS-1696, we wanted to perform reconciliation in the master based on the version of the slave. In both cases, when we don't have the version, we have to either rely on hacks/tricks, or add additional phases. was: Message versioning in Mesos provides a number of benefits: # Prevent incompatible version combinations. For example, we want to reject slaves that are 1 version behind the master. # The biggest win is providing the ability to determine behavior based on the cross-component versioning. For example, in MESOS-1668 we wanted the master to send a different ping message based on the version of the slave. In MESOS-1696, we wanted to perform reconciliation in the master based on the version of the slave. In both cases, when we don't have the version, we have to either rely on hacks/tricks, or add additional phases. Add versioning to messages. --- Key: MESOS-986 URL: https://issues.apache.org/jira/browse/MESOS-986 Project: Mesos Issue Type: Improvement Reporter: Benjamin Mahler Message versioning in Mesos provides a number of benefits: (1) Prevent incompatible version combinations. For example, we want to reject slaves that are 1 version behind the master. (2) The biggest win is providing the ability to determine behavior based on the cross-component versioning. For example, in MESOS-1668 we wanted the master to send a different ping message based on the version of the slave. In MESOS-1696, we wanted to perform reconciliation in the master based on the version of the slave. In both cases, when we don't have the version, we have to either rely on hacks/tricks, or add additional phases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
