[jira] [Assigned] (MESOS-3727) File permission inconsistency for mesos-master executable and mesos-init-wrapper.
[ https://issues.apache.org/jira/browse/MESOS-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo reassigned MESOS-3727: -- Assignee: Jay Guo > File permission inconsistency for mesos-master executable and > mesos-init-wrapper. > - > > Key: MESOS-3727 > URL: https://issues.apache.org/jira/browse/MESOS-3727 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.25.0 >Reporter: Sarjeet Singh >Assignee: Jay Guo >Priority: Trivial > > There seems some file permission inconsistency for mesos-master executable > and mesos-init-wrapper script with mesos-version 0.25. > node-1:~# dpkg -l | grep mesos > ii mesos 0.25.0-0.2.70.ubuntu1404 > node-1:~# ls -ld /usr/sbin/mesos-master > -rwxr-xr-x 1 root root 289173 Oct 12 14:07 /usr/sbin/mesos-master > node-1:~# ls -ld /usr/bin/mesos-init-wrapper > -rwxrwx--- 1 root root 5202 Oct 1 11:17 /usr/bin/mesos-init-wrapper > Observed the issue when tried to execute the mesos-master executable with > non-root user and since, init-wrapper doesn't have any non-root user > permission, it didn't get executed and mesos-master didn't get started. > Should be make these file permission consistent for executable & init-script? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3481) Add const accessor to Master flags
[ https://issues.apache.org/jira/browse/MESOS-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhou xing reassigned MESOS-3481: Assignee: zhou xing > Add const accessor to Master flags > -- > > Key: MESOS-3481 > URL: https://issues.apache.org/jira/browse/MESOS-3481 > Project: Mesos > Issue Type: Task >Reporter: Joseph Wu >Assignee: zhou xing >Priority: Trivial > Labels: mesosphere, newbie > > It would make sense to have an accessor to the master's flags, especially for > tests. > For example, see [this > test|https://github.com/apache/mesos/blob/2876b8c918814347dd56f6f87d461e414a90650a/src/tests/master_maintenance_tests.cpp#L1231-L1235]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4671) Status updates from executor can be forwarded out of order by the Agent.
[
https://issues.apache.org/jira/browse/MESOS-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146882#comment-15146882
]
Avinash Sridharan commented on MESOS-4671:
--
Hi [~klaus1982],
Sorry didn't understand your comment?
> Status updates from executor can be forwarded out of order by the Agent.
>
>
> Key: MESOS-4671
> URL: https://issues.apache.org/jira/browse/MESOS-4671
> Project: Mesos
> Issue Type: Bug
> Components: containerization, HTTP API
>Affects Versions: 0.28.0
>Reporter: Anand Mazumdar
>Assignee: Avinash Sridharan
> Labels: mesosphere
>
> Previously, all status update messages from the executor were forwarded by
> the agent to the master in the order that they had been received.
> However, that seems to be no longer valid due to a recently introduced change
> in the agent:
> {code}
> // Before sending update, we need to retrieve the container status.
> containerizer->status(executor->containerId)
> .onAny(defer(self(),
> &Slave::_statusUpdate,
> update,
> pid,
> executor->id,
> lambda::_1));
> {code}
> This can sometimes lead to status updates being sent out of order depending
> on the order the {{Future}} is fulfilled from the call to {{status(...)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4671) Status updates from executor can be forwarded out of order by the Agent.
[
https://issues.apache.org/jira/browse/MESOS-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146874#comment-15146874
]
Klaus Ma commented on MESOS-4671:
-
In {{MesosContainerizerProcess}}, it'll also handle {{status}} in order; is it
possible to return {{FINISHED}} before {{RUNNING}} for {{StatusUpdate}}?
> Status updates from executor can be forwarded out of order by the Agent.
>
>
> Key: MESOS-4671
> URL: https://issues.apache.org/jira/browse/MESOS-4671
> Project: Mesos
> Issue Type: Bug
> Components: containerization, HTTP API
>Affects Versions: 0.28.0
>Reporter: Anand Mazumdar
>Assignee: Avinash Sridharan
> Labels: mesosphere
>
> Previously, all status update messages from the executor were forwarded by
> the agent to the master in the order that they had been received.
> However, that seems to be no longer valid due to a recently introduced change
> in the agent:
> {code}
> // Before sending update, we need to retrieve the container status.
> containerizer->status(executor->containerId)
> .onAny(defer(self(),
> &Slave::_statusUpdate,
> update,
> pid,
> executor->id,
> lambda::_1));
> {code}
> This can sometimes lead to status updates being sent out of order depending
> on the order the {{Future}} is fulfilled from the call to {{status(...)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1719) Master should persist active frameworks information
[ https://issues.apache.org/jira/browse/MESOS-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146833#comment-15146833 ] Yongqiao Wang commented on MESOS-1719: -- [~kaysoky], Thanks for your reply. Is there some docs for "state abstraction"? I am not sure this function can address the problems referred as above of this ticket. > Master should persist active frameworks information > --- > > Key: MESOS-1719 > URL: https://issues.apache.org/jira/browse/MESOS-1719 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Yongqiao Wang > > https://issues.apache.org/jira/browse/MESOS-1219 disallows completed > frameworks from re-registering with the same framework id, as long as the > master doesn't failover. > This ticket tracks the work for it work across the master failover using > registrar. > There are some open questions that need to be addressed: > --> Should registry contain framework ids only framework infos. > For disallowing completed frameworks from re-registering, persisting > framework ids is enough. But, if in the future, we want to disallow > frameworks from re-registering if some parts of framework info > changed then we need to persist the info too. > --> How to update the framework info. > Currently frameworks are allowed to update framework info while re- > registering, but it only takes effect on the master when the master > fails > over and on the slave when the slave fails over. How should things >change when persist framework info? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4671) Status updates from executor can be forwarded out of order by the Agent.
[
https://issues.apache.org/jira/browse/MESOS-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146809#comment-15146809
]
Avinash Sridharan commented on MESOS-4671:
--
>From the logs attached to MESOS-4661 it does look like the status updates for
>TASK_RUNNING and TASK_FINISHED got inverted. Here are the relevant logs:
I0212 00:23:11.639288 731 slave.cpp:3002] Handling status update TASK_RUNNING
(UUID: b0810058-a1c0-4918-b699-61c16eb0f46a) for task 1 of framework
6508f198-e145-4d76-844f-0460dc5d7d39-
I0212 00:23:11.639622 731 slave.cpp:3002] Handling status update
TASK_FINISHED (UUID: 4674114a-c022-4945-ac98-52c0fae325e5) for task 1 of
framework 6508f198-e145-4d76-844f-0460dc5d7d39-
I0212 00:23:11.641832 729 slave.cpp:5661] Terminating task 1
I0212 00:23:11.643185 721 status_update_manager.cpp:320] Received status
update TASK_FINISHED (UUID: 4674114a-c022-4945-ac98-52c0fae325e5) for task 1 of
framework 6508f198-e145-4d76-844f-0460dc5d7d39-
I0212 00:23:11.643405 7480 executor.cpp:588] Enqueuing event SUBSCRIBED
received from http://172.17.0.2:57200/slave/api/v1/executor
I0212 00:23:11.643427 721 status_update_manager.cpp:497] Creating
StatusUpdate stream for task 1 of framework
6508f198-e145-4d76-844f-0460dc5d7d39-
I0212 00:23:11.644057 721 status_update_manager.cpp:824] Checkpointing UPDATE
for status update TASK_FINISHED (UUID: 4674114a-c022-4945-ac98-52c0fae325e5)
for task 1 of framework 6508f198-e145-4d76-844f-0460dc5d7d39-
Received a SUBSCRIBED event
Since `dispatch` maintains the causality of events in a `process`, as long as
the messages go through the same set of `processes` we should never see a
re-ordering of events. However, the implementation of the status method in
`MesosContainerizer` uses `await` to collect all the `ContainerStatus`
`Futures` from the isolators, before completing the `Promise` given to the
agent. The `await` method internally launches a `process` to wait for these
futures. Thus, due to the use of `await` multiple `StatusUpdate` messages might
end up being processed by a different set of `libprocess` thread causing a race.
> Status updates from executor can be forwarded out of order by the Agent.
>
>
> Key: MESOS-4671
> URL: https://issues.apache.org/jira/browse/MESOS-4671
> Project: Mesos
> Issue Type: Bug
> Components: containerization, HTTP API
>Affects Versions: 0.28.0
>Reporter: Anand Mazumdar
>Assignee: Avinash Sridharan
> Labels: mesosphere
>
> Previously, all status update messages from the executor were forwarded by
> the agent to the master in the order that they had been received.
> However, that seems to be no longer valid due to a recently introduced change
> in the agent:
> {code}
> // Before sending update, we need to retrieve the container status.
> containerizer->status(executor->containerId)
> .onAny(defer(self(),
> &Slave::_statusUpdate,
> update,
> pid,
> executor->id,
> lambda::_1));
> {code}
> This can sometimes lead to status updates being sent out of order depending
> on the order the {{Future}} is fulfilled from the call to {{status(...)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4671) Status updates from executor can be forwarded out of order by the Agent.
[
https://issues.apache.org/jira/browse/MESOS-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avinash Sridharan reassigned MESOS-4671:
Assignee: Avinash Sridharan
> Status updates from executor can be forwarded out of order by the Agent.
>
>
> Key: MESOS-4671
> URL: https://issues.apache.org/jira/browse/MESOS-4671
> Project: Mesos
> Issue Type: Bug
> Components: containerization, HTTP API
>Affects Versions: 0.28.0
>Reporter: Anand Mazumdar
>Assignee: Avinash Sridharan
> Labels: mesosphere
>
> Previously, all status update messages from the executor were forwarded by
> the agent to the master in the order that they had been received.
> However, that seems to be no longer valid due to a recently introduced change
> in the agent:
> {code}
> // Before sending update, we need to retrieve the container status.
> containerizer->status(executor->containerId)
> .onAny(defer(self(),
> &Slave::_statusUpdate,
> update,
> pid,
> executor->id,
> lambda::_1));
> {code}
> This can sometimes lead to status updates being sent out of order depending
> on the order the {{Future}} is fulfilled from the call to {{status(...)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4672) Implement aufs based provisioner backend.
[ https://issues.apache.org/jira/browse/MESOS-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuai Lin reassigned MESOS-4672: Assignee: Shuai Lin > Implement aufs based provisioner backend. > - > > Key: MESOS-4672 > URL: https://issues.apache.org/jira/browse/MESOS-4672 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Shuai Lin > > Overlay fs support hasn't been merged until kernel 3.18. Docker's default > storage backend for ubuntu 14.04 is aufs. We should consider adding a aufs > based backend for unified containerizer as well to efficiently provide a > union fs (instead of relying on copy backend which is not space efficient). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4413) IOTest.BufferedRead is flaky
[
https://issues.apache.org/jira/browse/MESOS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146797#comment-15146797
]
Klaus Ma commented on MESOS-4413:
-
The signal is the same. If {{libprocess-tests}} doesn't crash because of
{{SIGSTOP}}, it will continue after read.
> IOTest.BufferedRead is flaky
>
>
> Key: MESOS-4413
> URL: https://issues.apache.org/jira/browse/MESOS-4413
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: Darwin Klauss-MacBook-Pro.local 15.2.0 Darwin Kernel
> Version 15.2.0: Fri Nov 13 19:56:56 PST 2015;
> root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64
>Reporter: Klaus Ma
>
> {code}
> ./libprocess-tests
> [==] Running 155 tests from 23 test cases.
> [--] Global test environment set-up.
> [--] 3 tests from CollectTest
> [ RUN ] CollectTest.Ready
> [ OK ] CollectTest.Ready (1 ms)
> [ RUN ] CollectTest.Failure
> [ OK ] CollectTest.Failure (1 ms)
> [ RUN ] CollectTest.DiscardPropagation
> [ OK ] CollectTest.DiscardPropagation (1 ms)
> [--] 3 tests from CollectTest (3 ms total)
> [--] 4 tests from AwaitTest
> [ RUN ] AwaitTest.Success
> [ OK ] AwaitTest.Success (0 ms)
> [ RUN ] AwaitTest.Failure
> [ OK ] AwaitTest.Failure (1 ms)
> [ RUN ] AwaitTest.Discarded
> [ OK ] AwaitTest.Discarded (0 ms)
> [ RUN ] AwaitTest.DiscardPropagation
> [ OK ] AwaitTest.DiscardPropagation (0 ms)
> [--] 4 tests from AwaitTest (1 ms total)
> [--] 6 tests from DecoderTest
> [ RUN ] DecoderTest.Request
> [ OK ] DecoderTest.Request (1 ms)
> [ RUN ] DecoderTest.RequestHeaderContinuation
> [ OK ] DecoderTest.RequestHeaderContinuation (0 ms)
> [ RUN ] DecoderTest.RequestHeaderCaseInsensitive
> [ OK ] DecoderTest.RequestHeaderCaseInsensitive (0 ms)
> [ RUN ] DecoderTest.Response
> [ OK ] DecoderTest.Response (0 ms)
> [ RUN ] DecoderTest.StreamingResponse
> [ OK ] DecoderTest.StreamingResponse (0 ms)
> [ RUN ] DecoderTest.StreamingResponseFailure
> [ OK ] DecoderTest.StreamingResponseFailure (0 ms)
> [--] 6 tests from DecoderTest (1 ms total)
> [--] 2 tests from EncoderTest
> [ RUN ] EncoderTest.Response
> [ OK ] EncoderTest.Response (0 ms)
> [ RUN ] EncoderTest.AcceptableEncodings
> [ OK ] EncoderTest.AcceptableEncodings (1 ms)
> [--] 2 tests from EncoderTest (1 ms total)
> [--] 1 test from FutureTest
> [ RUN ] FutureTest.ArrowOperator
> [ OK ] FutureTest.ArrowOperator (0 ms)
> [--] 1 test from FutureTest (0 ms total)
> [--] 17 tests from HTTPTest
> [ RUN ] HTTPTest.Auth
> [ OK ] HTTPTest.Auth (5 ms)
> [ RUN ] HTTPTest.Endpoints
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0116 15:26:53.831742 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPTest.Endpoints (3 ms)
> [ RUN ] HTTPTest.PipeEOF
> [ OK ] HTTPTest.PipeEOF (0 ms)
> [ RUN ] HTTPTest.PipeFailure
> [ OK ] HTTPTest.PipeFailure (1 ms)
> [ RUN ] HTTPTest.PipeReaderCloses
> [ OK ] HTTPTest.PipeReaderCloses (0 ms)
> [ RUN ] HTTPTest.Encode
> [ OK ] HTTPTest.Encode (0 ms)
> [ RUN ] HTTPTest.PathParse
> [ OK ] HTTPTest.PathParse (0 ms)
> [ RUN ] HTTPTest.Get
> [ OK ] HTTPTest.Get (3 ms)
> [ RUN ] HTTPTest.NestedGet
> [ OK ] HTTPTest.NestedGet (4 ms)
> [ RUN ] HTTPTest.StreamingGetComplete
> [ OK ] HTTPTest.StreamingGetComplete (3 ms)
> [ RUN ] HTTPTest.StreamingGetFailure
> [ OK ] HTTPTest.StreamingGetFailure (3 ms)
> [ RUN ] HTTPTest.PipeEquality
> [ OK ] HTTPTest.PipeEquality (0 ms)
> [ RUN ] HTTPTest.Post
> [ OK ] HTTPTest.Post (3 ms)
> [ RUN ] HTTPTest.Delete
> [ OK ] HTTPTest.Delete (1 ms)
> [ RUN ] HTTPTest.QueryEncodeDecode
> [ OK ] HTTPTest.QueryEncodeDecode (1 ms)
> [ RUN ] HTTPTest.CaseInsensitiveHeaders
> [ OK ] HTTPTest.CaseInsensitiveHeaders (0 ms)
> [ RUN ] HTTPTest.Accepts
> [ OK ] HTTPTest.Accepts (0 ms)
> [--] 17 tests from HTTPTest (28 ms total)
> [--] 6 tests from HTTPConnectionTest
> [ RUN ] HTTPConnectionTest.Serial
> E0116 15:26:53.856267 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPConnectionTest.Serial (5 ms)
> [ RUN ] HTTPConnectionTest.Pipeline
> E0116 15:26:53.861946 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPConnectionTest.Pipeline (6 ms)
> [ RUN ] HTTPConnectionTest.ClosingRequest
> [ OK ] HTTPConnectionTest.ClosingReques
[jira] [Commented] (MESOS-3486) Use DROP_PROTOBUF instead of DROP_MESSAGE in tests
[ https://issues.apache.org/jira/browse/MESOS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146770#comment-15146770 ] Michael Browning commented on MESOS-3486: - Actually, this holds for DROP_PROTOBUF (which also invokes FutureProtobuf) in a number of cases too, viz: Future registerExecutorMessage = DROP_MESSAGE(Eq(RegisterExecutorMessage().GetTypeName()), _, _); DROP_PROTOBUF would return an RegisterExecutorMessage, which is a subclass of ::google::protobuf::Message, and not an instance of process::Message. > Use DROP_PROTOBUF instead of DROP_MESSAGE in tests > -- > > Key: MESOS-3486 > URL: https://issues.apache.org/jira/browse/MESOS-3486 > Project: Mesos > Issue Type: Improvement >Reporter: Neil Conway >Assignee: Michael Browning >Priority: Trivial > Labels: mesosphere, newbie, tests > > The tests use DROP_MESSAGE(), DROP_MESSAGES(), and FUTURE_MESSAGE() in > various places where it would be more clear and concise to use > DROP_PROTOBUF(), DROP_PROTOBUFS(), and FUTURE_PROTOBUF() instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3486) Use DROP_PROTOBUF instead of DROP_MESSAGE in tests
[ https://issues.apache.org/jira/browse/MESOS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146764#comment-15146764 ] Michael Browning commented on MESOS-3486: - I'm not sure it makes sense to use FUTURE_PROTOBUF instead of FUTURE_MESSAGE in the test suite -- FUTURE_PROTOBUF's return type is that of its first argument, where FUTURE_MESSAGE returns process::Message. A typical case (from tests/cram_md5_authentication_tests.cpp) is: Future message = FUTURE_MESSAGE(Eq(AuthenticateMessage().GetTypeName()), _, _); If we replace this with the following (instantiation of Eq removed, since that occurs inside FutureProtobuf already): Future message = FUTURE_PROTOBUF(AuthenticateMessage(), _, _); We're actually getting an AuthenticateMessage back, which isn't at all related to process::Message (it's a subclass of the protoc Message class). Needless to say, this doesn't work when later statements in the test expect a process::Message to be living in that Future instance. I think all instances of FUTURE_MESSAGE should remain as is. > Use DROP_PROTOBUF instead of DROP_MESSAGE in tests > -- > > Key: MESOS-3486 > URL: https://issues.apache.org/jira/browse/MESOS-3486 > Project: Mesos > Issue Type: Improvement >Reporter: Neil Conway >Assignee: Michael Browning >Priority: Trivial > Labels: mesosphere, newbie, tests > > The tests use DROP_MESSAGE(), DROP_MESSAGES(), and FUTURE_MESSAGE() in > various places where it would be more clear and concise to use > DROP_PROTOBUF(), DROP_PROTOBUFS(), and FUTURE_PROTOBUF() instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4672) Implement aufs based provisioner backend.
Jie Yu created MESOS-4672: - Summary: Implement aufs based provisioner backend. Key: MESOS-4672 URL: https://issues.apache.org/jira/browse/MESOS-4672 Project: Mesos Issue Type: Bug Reporter: Jie Yu Overlay fs support hasn't been merged until kernel 3.18. Docker's default storage backend for ubuntu 14.04 is aufs. We should consider adding a aufs based backend for unified containerizer as well to efficiently provide a union fs (instead of relying on copy backend which is not space efficient). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4413) IOTest.BufferedRead is flaky
[
https://issues.apache.org/jira/browse/MESOS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146617#comment-15146617
]
haosdent commented on MESOS-4413:
-
Hmm, yes. Because nobody read from pipe, write to pipe would hang once read the
limit of buffer.
> IOTest.BufferedRead is flaky
>
>
> Key: MESOS-4413
> URL: https://issues.apache.org/jira/browse/MESOS-4413
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: Darwin Klauss-MacBook-Pro.local 15.2.0 Darwin Kernel
> Version 15.2.0: Fri Nov 13 19:56:56 PST 2015;
> root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64
>Reporter: Klaus Ma
>
> {code}
> ./libprocess-tests
> [==] Running 155 tests from 23 test cases.
> [--] Global test environment set-up.
> [--] 3 tests from CollectTest
> [ RUN ] CollectTest.Ready
> [ OK ] CollectTest.Ready (1 ms)
> [ RUN ] CollectTest.Failure
> [ OK ] CollectTest.Failure (1 ms)
> [ RUN ] CollectTest.DiscardPropagation
> [ OK ] CollectTest.DiscardPropagation (1 ms)
> [--] 3 tests from CollectTest (3 ms total)
> [--] 4 tests from AwaitTest
> [ RUN ] AwaitTest.Success
> [ OK ] AwaitTest.Success (0 ms)
> [ RUN ] AwaitTest.Failure
> [ OK ] AwaitTest.Failure (1 ms)
> [ RUN ] AwaitTest.Discarded
> [ OK ] AwaitTest.Discarded (0 ms)
> [ RUN ] AwaitTest.DiscardPropagation
> [ OK ] AwaitTest.DiscardPropagation (0 ms)
> [--] 4 tests from AwaitTest (1 ms total)
> [--] 6 tests from DecoderTest
> [ RUN ] DecoderTest.Request
> [ OK ] DecoderTest.Request (1 ms)
> [ RUN ] DecoderTest.RequestHeaderContinuation
> [ OK ] DecoderTest.RequestHeaderContinuation (0 ms)
> [ RUN ] DecoderTest.RequestHeaderCaseInsensitive
> [ OK ] DecoderTest.RequestHeaderCaseInsensitive (0 ms)
> [ RUN ] DecoderTest.Response
> [ OK ] DecoderTest.Response (0 ms)
> [ RUN ] DecoderTest.StreamingResponse
> [ OK ] DecoderTest.StreamingResponse (0 ms)
> [ RUN ] DecoderTest.StreamingResponseFailure
> [ OK ] DecoderTest.StreamingResponseFailure (0 ms)
> [--] 6 tests from DecoderTest (1 ms total)
> [--] 2 tests from EncoderTest
> [ RUN ] EncoderTest.Response
> [ OK ] EncoderTest.Response (0 ms)
> [ RUN ] EncoderTest.AcceptableEncodings
> [ OK ] EncoderTest.AcceptableEncodings (1 ms)
> [--] 2 tests from EncoderTest (1 ms total)
> [--] 1 test from FutureTest
> [ RUN ] FutureTest.ArrowOperator
> [ OK ] FutureTest.ArrowOperator (0 ms)
> [--] 1 test from FutureTest (0 ms total)
> [--] 17 tests from HTTPTest
> [ RUN ] HTTPTest.Auth
> [ OK ] HTTPTest.Auth (5 ms)
> [ RUN ] HTTPTest.Endpoints
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0116 15:26:53.831742 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPTest.Endpoints (3 ms)
> [ RUN ] HTTPTest.PipeEOF
> [ OK ] HTTPTest.PipeEOF (0 ms)
> [ RUN ] HTTPTest.PipeFailure
> [ OK ] HTTPTest.PipeFailure (1 ms)
> [ RUN ] HTTPTest.PipeReaderCloses
> [ OK ] HTTPTest.PipeReaderCloses (0 ms)
> [ RUN ] HTTPTest.Encode
> [ OK ] HTTPTest.Encode (0 ms)
> [ RUN ] HTTPTest.PathParse
> [ OK ] HTTPTest.PathParse (0 ms)
> [ RUN ] HTTPTest.Get
> [ OK ] HTTPTest.Get (3 ms)
> [ RUN ] HTTPTest.NestedGet
> [ OK ] HTTPTest.NestedGet (4 ms)
> [ RUN ] HTTPTest.StreamingGetComplete
> [ OK ] HTTPTest.StreamingGetComplete (3 ms)
> [ RUN ] HTTPTest.StreamingGetFailure
> [ OK ] HTTPTest.StreamingGetFailure (3 ms)
> [ RUN ] HTTPTest.PipeEquality
> [ OK ] HTTPTest.PipeEquality (0 ms)
> [ RUN ] HTTPTest.Post
> [ OK ] HTTPTest.Post (3 ms)
> [ RUN ] HTTPTest.Delete
> [ OK ] HTTPTest.Delete (1 ms)
> [ RUN ] HTTPTest.QueryEncodeDecode
> [ OK ] HTTPTest.QueryEncodeDecode (1 ms)
> [ RUN ] HTTPTest.CaseInsensitiveHeaders
> [ OK ] HTTPTest.CaseInsensitiveHeaders (0 ms)
> [ RUN ] HTTPTest.Accepts
> [ OK ] HTTPTest.Accepts (0 ms)
> [--] 17 tests from HTTPTest (28 ms total)
> [--] 6 tests from HTTPConnectionTest
> [ RUN ] HTTPConnectionTest.Serial
> E0116 15:26:53.856267 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPConnectionTest.Serial (5 ms)
> [ RUN ] HTTPConnectionTest.Pipeline
> E0116 15:26:53.861946 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPConnectionTest.Pipeline (6 ms)
> [ RUN ] HTTPConnectionTest.ClosingRequest
> [ OK ] HTTPConnectionTest.ClosingRequest (4 ms)
> [ RUN
[jira] [Commented] (MESOS-4413) IOTest.BufferedRead is flaky
[
https://issues.apache.org/jira/browse/MESOS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146564#comment-15146564
]
Klaus Ma commented on MESOS-4413:
-
It seems related with OS configuration on pipe's buffer. I dump the code in
{{write.hpp}} into a simple code
(https://github.com/klaus1982/mics/blob/master/linux/write.cpp); it'll hang
because of {{SIGSTOP}}, and pass with smaller data size.
> IOTest.BufferedRead is flaky
>
>
> Key: MESOS-4413
> URL: https://issues.apache.org/jira/browse/MESOS-4413
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: Darwin Klauss-MacBook-Pro.local 15.2.0 Darwin Kernel
> Version 15.2.0: Fri Nov 13 19:56:56 PST 2015;
> root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64
>Reporter: Klaus Ma
>
> {code}
> ./libprocess-tests
> [==] Running 155 tests from 23 test cases.
> [--] Global test environment set-up.
> [--] 3 tests from CollectTest
> [ RUN ] CollectTest.Ready
> [ OK ] CollectTest.Ready (1 ms)
> [ RUN ] CollectTest.Failure
> [ OK ] CollectTest.Failure (1 ms)
> [ RUN ] CollectTest.DiscardPropagation
> [ OK ] CollectTest.DiscardPropagation (1 ms)
> [--] 3 tests from CollectTest (3 ms total)
> [--] 4 tests from AwaitTest
> [ RUN ] AwaitTest.Success
> [ OK ] AwaitTest.Success (0 ms)
> [ RUN ] AwaitTest.Failure
> [ OK ] AwaitTest.Failure (1 ms)
> [ RUN ] AwaitTest.Discarded
> [ OK ] AwaitTest.Discarded (0 ms)
> [ RUN ] AwaitTest.DiscardPropagation
> [ OK ] AwaitTest.DiscardPropagation (0 ms)
> [--] 4 tests from AwaitTest (1 ms total)
> [--] 6 tests from DecoderTest
> [ RUN ] DecoderTest.Request
> [ OK ] DecoderTest.Request (1 ms)
> [ RUN ] DecoderTest.RequestHeaderContinuation
> [ OK ] DecoderTest.RequestHeaderContinuation (0 ms)
> [ RUN ] DecoderTest.RequestHeaderCaseInsensitive
> [ OK ] DecoderTest.RequestHeaderCaseInsensitive (0 ms)
> [ RUN ] DecoderTest.Response
> [ OK ] DecoderTest.Response (0 ms)
> [ RUN ] DecoderTest.StreamingResponse
> [ OK ] DecoderTest.StreamingResponse (0 ms)
> [ RUN ] DecoderTest.StreamingResponseFailure
> [ OK ] DecoderTest.StreamingResponseFailure (0 ms)
> [--] 6 tests from DecoderTest (1 ms total)
> [--] 2 tests from EncoderTest
> [ RUN ] EncoderTest.Response
> [ OK ] EncoderTest.Response (0 ms)
> [ RUN ] EncoderTest.AcceptableEncodings
> [ OK ] EncoderTest.AcceptableEncodings (1 ms)
> [--] 2 tests from EncoderTest (1 ms total)
> [--] 1 test from FutureTest
> [ RUN ] FutureTest.ArrowOperator
> [ OK ] FutureTest.ArrowOperator (0 ms)
> [--] 1 test from FutureTest (0 ms total)
> [--] 17 tests from HTTPTest
> [ RUN ] HTTPTest.Auth
> [ OK ] HTTPTest.Auth (5 ms)
> [ RUN ] HTTPTest.Endpoints
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0116 15:26:53.831742 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPTest.Endpoints (3 ms)
> [ RUN ] HTTPTest.PipeEOF
> [ OK ] HTTPTest.PipeEOF (0 ms)
> [ RUN ] HTTPTest.PipeFailure
> [ OK ] HTTPTest.PipeFailure (1 ms)
> [ RUN ] HTTPTest.PipeReaderCloses
> [ OK ] HTTPTest.PipeReaderCloses (0 ms)
> [ RUN ] HTTPTest.Encode
> [ OK ] HTTPTest.Encode (0 ms)
> [ RUN ] HTTPTest.PathParse
> [ OK ] HTTPTest.PathParse (0 ms)
> [ RUN ] HTTPTest.Get
> [ OK ] HTTPTest.Get (3 ms)
> [ RUN ] HTTPTest.NestedGet
> [ OK ] HTTPTest.NestedGet (4 ms)
> [ RUN ] HTTPTest.StreamingGetComplete
> [ OK ] HTTPTest.StreamingGetComplete (3 ms)
> [ RUN ] HTTPTest.StreamingGetFailure
> [ OK ] HTTPTest.StreamingGetFailure (3 ms)
> [ RUN ] HTTPTest.PipeEquality
> [ OK ] HTTPTest.PipeEquality (0 ms)
> [ RUN ] HTTPTest.Post
> [ OK ] HTTPTest.Post (3 ms)
> [ RUN ] HTTPTest.Delete
> [ OK ] HTTPTest.Delete (1 ms)
> [ RUN ] HTTPTest.QueryEncodeDecode
> [ OK ] HTTPTest.QueryEncodeDecode (1 ms)
> [ RUN ] HTTPTest.CaseInsensitiveHeaders
> [ OK ] HTTPTest.CaseInsensitiveHeaders (0 ms)
> [ RUN ] HTTPTest.Accepts
> [ OK ] HTTPTest.Accepts (0 ms)
> [--] 17 tests from HTTPTest (28 ms total)
> [--] 6 tests from HTTPConnectionTest
> [ RUN ] HTTPConnectionTest.Serial
> E0116 15:26:53.856267 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPConnectionTest.Serial (5 ms)
> [ RUN ] HTTPConnectionTest.Pipeline
> E0116 15:26:53.861946 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HT
[jira] [Commented] (MESOS-4413) IOTest.BufferedRead is flaky
[
https://issues.apache.org/jira/browse/MESOS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146526#comment-15146526
]
Klaus Ma commented on MESOS-4413:
-
similar environment to yours:
{code}
Klauss-MacBook-Pro:mesos klaus$ otool -L
build/3rdparty/libprocess/libprocess-tests
build/3rdparty/libprocess/libprocess-tests:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version
8.0.0)
/usr/local/opt/subversion/lib/libsvn_delta-1.0.dylib (compatibility
version 1.0.0, current version 1.0.0)
/usr/local/opt/subversion/lib/libsvn_subr-1.0.dylib (compatibility
version 1.0.0, current version 1.0.0)
/usr/lib/libapr-1.0.dylib (compatibility version 5.0.0, current version
5.8.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.1.0)
Klauss-MacBook-Pro:mesos klaus$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
{code}
> IOTest.BufferedRead is flaky
>
>
> Key: MESOS-4413
> URL: https://issues.apache.org/jira/browse/MESOS-4413
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: Darwin Klauss-MacBook-Pro.local 15.2.0 Darwin Kernel
> Version 15.2.0: Fri Nov 13 19:56:56 PST 2015;
> root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64
>Reporter: Klaus Ma
>
> {code}
> ./libprocess-tests
> [==] Running 155 tests from 23 test cases.
> [--] Global test environment set-up.
> [--] 3 tests from CollectTest
> [ RUN ] CollectTest.Ready
> [ OK ] CollectTest.Ready (1 ms)
> [ RUN ] CollectTest.Failure
> [ OK ] CollectTest.Failure (1 ms)
> [ RUN ] CollectTest.DiscardPropagation
> [ OK ] CollectTest.DiscardPropagation (1 ms)
> [--] 3 tests from CollectTest (3 ms total)
> [--] 4 tests from AwaitTest
> [ RUN ] AwaitTest.Success
> [ OK ] AwaitTest.Success (0 ms)
> [ RUN ] AwaitTest.Failure
> [ OK ] AwaitTest.Failure (1 ms)
> [ RUN ] AwaitTest.Discarded
> [ OK ] AwaitTest.Discarded (0 ms)
> [ RUN ] AwaitTest.DiscardPropagation
> [ OK ] AwaitTest.DiscardPropagation (0 ms)
> [--] 4 tests from AwaitTest (1 ms total)
> [--] 6 tests from DecoderTest
> [ RUN ] DecoderTest.Request
> [ OK ] DecoderTest.Request (1 ms)
> [ RUN ] DecoderTest.RequestHeaderContinuation
> [ OK ] DecoderTest.RequestHeaderContinuation (0 ms)
> [ RUN ] DecoderTest.RequestHeaderCaseInsensitive
> [ OK ] DecoderTest.RequestHeaderCaseInsensitive (0 ms)
> [ RUN ] DecoderTest.Response
> [ OK ] DecoderTest.Response (0 ms)
> [ RUN ] DecoderTest.StreamingResponse
> [ OK ] DecoderTest.StreamingResponse (0 ms)
> [ RUN ] DecoderTest.StreamingResponseFailure
> [ OK ] DecoderTest.StreamingResponseFailure (0 ms)
> [--] 6 tests from DecoderTest (1 ms total)
> [--] 2 tests from EncoderTest
> [ RUN ] EncoderTest.Response
> [ OK ] EncoderTest.Response (0 ms)
> [ RUN ] EncoderTest.AcceptableEncodings
> [ OK ] EncoderTest.AcceptableEncodings (1 ms)
> [--] 2 tests from EncoderTest (1 ms total)
> [--] 1 test from FutureTest
> [ RUN ] FutureTest.ArrowOperator
> [ OK ] FutureTest.ArrowOperator (0 ms)
> [--] 1 test from FutureTest (0 ms total)
> [--] 17 tests from HTTPTest
> [ RUN ] HTTPTest.Auth
> [ OK ] HTTPTest.Auth (5 ms)
> [ RUN ] HTTPTest.Endpoints
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0116 15:26:53.831742 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPTest.Endpoints (3 ms)
> [ RUN ] HTTPTest.PipeEOF
> [ OK ] HTTPTest.PipeEOF (0 ms)
> [ RUN ] HTTPTest.PipeFailure
> [ OK ] HTTPTest.PipeFailure (1 ms)
> [ RUN ] HTTPTest.PipeReaderCloses
> [ OK ] HTTPTest.PipeReaderCloses (0 ms)
> [ RUN ] HTTPTest.Encode
> [ OK ] HTTPTest.Encode (0 ms)
> [ RUN ] HTTPTest.PathParse
> [ OK ] HTTPTest.PathParse (0 ms)
> [ RUN ] HTTPTest.Get
> [ OK ] HTTPTest.Get (3 ms)
> [ RUN ] HTTPTest.NestedGet
> [ OK ] HTTPTest.NestedGet (4 ms)
> [ RUN ] HTTPTest.StreamingGetComplete
> [ OK ] HTTPTest.StreamingGetComplete (3 ms)
> [ RUN ] HTTPTest.StreamingGetFailure
> [ OK ] HTTPTest.StreamingGetFailure (3 ms)
> [ RUN ] HTTPTest.PipeEquality
> [ OK ] HTTPTest.PipeEquality (0 ms)
> [ RUN ] HTTPT
[jira] [Commented] (MESOS-3193) Implement AppC image discovery.
[ https://issues.apache.org/jira/browse/MESOS-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146466#comment-15146466 ] Shuai Lin commented on MESOS-3193: -- Hi [~jojy], as you mentioned above simple discovery has been removed from appc spec (in [this github PR|https://github.com/appc/spec/pull/559], so I doubt does it still make sense to implement the simple discovery in your patch? > Implement AppC image discovery. > --- > > Key: MESOS-3193 > URL: https://issues.apache.org/jira/browse/MESOS-3193 > Project: Mesos > Issue Type: Task >Reporter: Yan Xu >Assignee: Jojy Varghese > Labels: mesosphere, twitter, unified-containerizer-mvp > > Appc spec specifies two image discovery mechanisms: simple and meta > discovery. We need to have an abstraction for image discovery in AppcStore. > For MVP, we can implement the simple discovery first. > https://reviews.apache.org/r/34139/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4413) IOTest.BufferedRead is flaky
[
https://issues.apache.org/jira/browse/MESOS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146455#comment-15146455
]
haosdent commented on MESOS-4413:
-
No ideas. I saw the code failed when
{code}
Future future = io::read(pipes[0]);
ASSERT_FALSE(future.isReady());
-> ASSERT_SOME(os::write(pipes[1], data));
ASSERT_SOME(os::close(pipes[1]));
{code}
But it works in my side.
{code}
./3rdparty/libprocess/libprocess-tests --gtest_filter=IOTest.BufferedRead
Note: Google Test filter = IOTest.BufferedRead
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from IOTest
[ RUN ] IOTest.BufferedRead
[ OK ] IOTest.BufferedRead (5 ms)
[--] 1 test from IOTest (5 ms total)
[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (5 ms total)
[ PASSED ] 1 test.
{code}
My ulimit is
{code}
ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 709
-n: file descriptors4864
{code}
Clang version
{code}
g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
{code}
> IOTest.BufferedRead is flaky
>
>
> Key: MESOS-4413
> URL: https://issues.apache.org/jira/browse/MESOS-4413
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Environment: Darwin Klauss-MacBook-Pro.local 15.2.0 Darwin Kernel
> Version 15.2.0: Fri Nov 13 19:56:56 PST 2015;
> root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64
>Reporter: Klaus Ma
>
> {code}
> ./libprocess-tests
> [==] Running 155 tests from 23 test cases.
> [--] Global test environment set-up.
> [--] 3 tests from CollectTest
> [ RUN ] CollectTest.Ready
> [ OK ] CollectTest.Ready (1 ms)
> [ RUN ] CollectTest.Failure
> [ OK ] CollectTest.Failure (1 ms)
> [ RUN ] CollectTest.DiscardPropagation
> [ OK ] CollectTest.DiscardPropagation (1 ms)
> [--] 3 tests from CollectTest (3 ms total)
> [--] 4 tests from AwaitTest
> [ RUN ] AwaitTest.Success
> [ OK ] AwaitTest.Success (0 ms)
> [ RUN ] AwaitTest.Failure
> [ OK ] AwaitTest.Failure (1 ms)
> [ RUN ] AwaitTest.Discarded
> [ OK ] AwaitTest.Discarded (0 ms)
> [ RUN ] AwaitTest.DiscardPropagation
> [ OK ] AwaitTest.DiscardPropagation (0 ms)
> [--] 4 tests from AwaitTest (1 ms total)
> [--] 6 tests from DecoderTest
> [ RUN ] DecoderTest.Request
> [ OK ] DecoderTest.Request (1 ms)
> [ RUN ] DecoderTest.RequestHeaderContinuation
> [ OK ] DecoderTest.RequestHeaderContinuation (0 ms)
> [ RUN ] DecoderTest.RequestHeaderCaseInsensitive
> [ OK ] DecoderTest.RequestHeaderCaseInsensitive (0 ms)
> [ RUN ] DecoderTest.Response
> [ OK ] DecoderTest.Response (0 ms)
> [ RUN ] DecoderTest.StreamingResponse
> [ OK ] DecoderTest.StreamingResponse (0 ms)
> [ RUN ] DecoderTest.StreamingResponseFailure
> [ OK ] DecoderTest.StreamingResponseFailure (0 ms)
> [--] 6 tests from DecoderTest (1 ms total)
> [--] 2 tests from EncoderTest
> [ RUN ] EncoderTest.Response
> [ OK ] EncoderTest.Response (0 ms)
> [ RUN ] EncoderTest.AcceptableEncodings
> [ OK ] EncoderTest.AcceptableEncodings (1 ms)
> [--] 2 tests from EncoderTest (1 ms total)
> [--] 1 test from FutureTest
> [ RUN ] FutureTest.ArrowOperator
> [ OK ] FutureTest.ArrowOperator (0 ms)
> [--] 1 test from FutureTest (0 ms total)
> [--] 17 tests from HTTPTest
> [ RUN ] HTTPTest.Auth
> [ OK ] HTTPTest.Auth (5 ms)
> [ RUN ] HTTPTest.Endpoints
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0116 15:26:53.831742 4820992 process.cpp:1966] Failed to shutdown socket
> with fd 9: Socket is not connected
> [ OK ] HTTPTest.Endpoints (3 ms)
> [ RUN ] HTTPTest.PipeEOF
> [ OK ] HTTPTest.PipeEOF (0 ms)
> [ RUN ] HTTPTest.PipeFailure
> [ OK ] HTTPTest.PipeFailure (1 ms)
> [ RUN ] HTTPTest.PipeReaderCloses
> [ OK ] HTTPTest.PipeReaderCloses (0 ms)
> [ RUN ] HTTPTest.Encode
> [ OK ] HTTPTest.Encode (0 ms)
> [ RUN ] HTTPTest.PathParse
> [ OK ] HTTPTest.PathParse (0 ms)
> [ RUN ] HTTPTest.Get
> [ OK ] HTTPTest.Get (3 ms)
> [ RUN ] HTTPTest.NestedGet
> [ OK ] HTTPTe
