[jira] [Commented] (MESOS-1740) Bad error message when docker containerizer isn't enabled
[
https://issues.apache.org/jira/browse/MESOS-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117772#comment-14117772
]
Timothy Chen commented on MESOS-1740:
-
I'll update it to use the first suggested message. I'd prefer not to check for
each derived class type from the base pointer in the slave.
> Bad error message when docker containerizer isn't enabled
> -
>
> Key: MESOS-1740
> URL: https://issues.apache.org/jira/browse/MESOS-1740
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Jay Buffington
>Assignee: Timothy Chen
>Priority: Minor
>
> If I set container in TaskInfo's executor (aka DockerInfo) but I do not start
> the slave with {{--containerizer=docker,...}} then I get this error message
> in the log:
> {noformat}
> E0827 17:53:16.422735 20090 slave.cpp:2491] Container 'xxx' for executor
> 'yyy' of framework 'zzz' failed to start: TaskInfo/ExecutorInfo not supported
> {noformat}
> A better error message would have been:
> {noformat}
> No enabled containerizers could create a container for the provided
> TaskInfo/ExecutorInfo message. Enabled containerizers are: mesos.
> {noformat}
> An even better error message would have been:
> {noformat}
> DockerInfo was sent, but docker containerizer is not enabled. Try adding
> --containerizer=docker,... to command line args
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1749) SlaveRecoveryTest.ShutdownSlave is flaky
[
https://issues.apache.org/jira/browse/MESOS-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117718#comment-14117718
]
Jie Yu commented on MESOS-1749:
---
https://reviews.apache.org/r/25207/
> SlaveRecoveryTest.ShutdownSlave is flaky
>
>
> Key: MESOS-1749
> URL: https://issues.apache.org/jira/browse/MESOS-1749
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.20.0
> Environment: ubuntu-13.10-gcc
>Reporter: Jie Yu
>Assignee: Jie Yu
>
> {noformat}
> [ RUN ] SlaveRecoveryTest/0.ShutdownSlave
> Using temporary directory '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS'
> I0828 21:21:46.206990 27625 leveldb.cpp:176] Opened db in 24.461837ms
> I0828 21:21:46.213706 27625 leveldb.cpp:183] Compacted db in 6.021499ms
> I0828 21:21:46.214047 27625 leveldb.cpp:198] Created db iterator in 5566ns
> I0828 21:21:46.214313 27625 leveldb.cpp:204] Seeked to beginning of db in
> 1433ns
> I0828 21:21:46.214515 27625 leveldb.cpp:273] Iterated through 0 keys in the
> db in 723ns
> I0828 21:21:46.214826 27625 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0828 21:21:46.215409 27642 recover.cpp:425] Starting replica recovery
> I0828 21:21:46.215718 27642 recover.cpp:451] Replica is in EMPTY status
> I0828 21:21:46.216264 27642 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I0828 21:21:46.216557 27642 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I0828 21:21:46.216917 27642 recover.cpp:542] Updating replica status to
> STARTING
> I0828 21:21:46.221271 27645 master.cpp:286] Master
> 20140828-212146-16842879-45613-27625 (saucy) started on 127.0.1.1:45613
> I0828 21:21:46.221812 27645 master.cpp:332] Master only allowing
> authenticated frameworks to register
> I0828 21:21:46.222038 27645 master.cpp:337] Master only allowing
> authenticated slaves to register
> I0828 21:21:46.50 27645 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS/credentials'
> I0828 21:21:46.222585 27645 master.cpp:366] Authorization enabled
> I0828 21:21:46.222885 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 5.596969ms
> I0828 21:21:46.223085 27642 replica.cpp:320] Persisted replica status to
> STARTING
> I0828 21:21:46.223424 27642 recover.cpp:451] Replica is in STARTING status
> I0828 21:21:46.223933 27642 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I0828 21:21:46.224984 27642 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I0828 21:21:46.225385 27642 recover.cpp:542] Updating replica status to VOTING
> I0828 21:21:46.224750 27646 master.cpp:1205] The newly elected leader is
> master@127.0.1.1:45613 with id 20140828-212146-16842879-45613-27625
> I0828 21:21:46.226132 27646 master.cpp:1218] Elected as the leading master!
> I0828 21:21:46.226349 27646 master.cpp:1036] Recovering from registrar
> I0828 21:21:46.226637 27646 registrar.cpp:313] Recovering registrar
> I0828 21:21:46.224473 27641 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I0828 21:21:46.224431 27645 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@127.0.1.1:45613
> I0828 21:21:46.240932 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 15.182422ms
> I0828 21:21:46.241453 27642 replica.cpp:320] Persisted replica status to
> VOTING
> I0828 21:21:46.241926 27643 recover.cpp:556] Successfully joined the Paxos
> group
> I0828 21:21:46.242228 27642 recover.cpp:440] Recover process terminated
> I0828 21:21:46.242501 27645 log.cpp:656] Attempting to start the writer
> I0828 21:21:46.243247 27645 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I0828 21:21:46.253456 27645 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 9.95472ms
> I0828 21:21:46.253955 27645 replica.cpp:342] Persisted promised to 1
> I0828 21:21:46.254518 27645 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I0828 21:21:46.255234 27641 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I0828 21:21:46.263128 27641 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 7.484042ms
> I0828 21:21:46.263536 27641 replica.cpp:676] Persisted action at 0
> I0828 21:21:46.263806 27641 replica.cpp:508] Replica received write request
> for position 0
> I0828 21:21:46.263834 27641 leveldb.cpp:438] Reading position from leveldb
> took 14063ns
> I0828 21:21:46.276149 27641 leveldb.cpp:343] Persisting action (14 bytes) to
> leveldb took 12.295476ms
> I0828 21:21:46.276178 27641 replica.cpp:6
[jira] [Updated] (MESOS-1749) SlaveRecoveryTest.ShutdownSlave is flaky
[
https://issues.apache.org/jira/browse/MESOS-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-1749:
--
Sprint: Q3 Sprint 4
Story Points: 2
> SlaveRecoveryTest.ShutdownSlave is flaky
>
>
> Key: MESOS-1749
> URL: https://issues.apache.org/jira/browse/MESOS-1749
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.20.0
> Environment: ubuntu-13.10-gcc
>Reporter: Jie Yu
>Assignee: Jie Yu
>
> {noformat}
> [ RUN ] SlaveRecoveryTest/0.ShutdownSlave
> Using temporary directory '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS'
> I0828 21:21:46.206990 27625 leveldb.cpp:176] Opened db in 24.461837ms
> I0828 21:21:46.213706 27625 leveldb.cpp:183] Compacted db in 6.021499ms
> I0828 21:21:46.214047 27625 leveldb.cpp:198] Created db iterator in 5566ns
> I0828 21:21:46.214313 27625 leveldb.cpp:204] Seeked to beginning of db in
> 1433ns
> I0828 21:21:46.214515 27625 leveldb.cpp:273] Iterated through 0 keys in the
> db in 723ns
> I0828 21:21:46.214826 27625 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0828 21:21:46.215409 27642 recover.cpp:425] Starting replica recovery
> I0828 21:21:46.215718 27642 recover.cpp:451] Replica is in EMPTY status
> I0828 21:21:46.216264 27642 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I0828 21:21:46.216557 27642 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I0828 21:21:46.216917 27642 recover.cpp:542] Updating replica status to
> STARTING
> I0828 21:21:46.221271 27645 master.cpp:286] Master
> 20140828-212146-16842879-45613-27625 (saucy) started on 127.0.1.1:45613
> I0828 21:21:46.221812 27645 master.cpp:332] Master only allowing
> authenticated frameworks to register
> I0828 21:21:46.222038 27645 master.cpp:337] Master only allowing
> authenticated slaves to register
> I0828 21:21:46.50 27645 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS/credentials'
> I0828 21:21:46.222585 27645 master.cpp:366] Authorization enabled
> I0828 21:21:46.222885 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 5.596969ms
> I0828 21:21:46.223085 27642 replica.cpp:320] Persisted replica status to
> STARTING
> I0828 21:21:46.223424 27642 recover.cpp:451] Replica is in STARTING status
> I0828 21:21:46.223933 27642 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I0828 21:21:46.224984 27642 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I0828 21:21:46.225385 27642 recover.cpp:542] Updating replica status to VOTING
> I0828 21:21:46.224750 27646 master.cpp:1205] The newly elected leader is
> master@127.0.1.1:45613 with id 20140828-212146-16842879-45613-27625
> I0828 21:21:46.226132 27646 master.cpp:1218] Elected as the leading master!
> I0828 21:21:46.226349 27646 master.cpp:1036] Recovering from registrar
> I0828 21:21:46.226637 27646 registrar.cpp:313] Recovering registrar
> I0828 21:21:46.224473 27641 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I0828 21:21:46.224431 27645 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@127.0.1.1:45613
> I0828 21:21:46.240932 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 15.182422ms
> I0828 21:21:46.241453 27642 replica.cpp:320] Persisted replica status to
> VOTING
> I0828 21:21:46.241926 27643 recover.cpp:556] Successfully joined the Paxos
> group
> I0828 21:21:46.242228 27642 recover.cpp:440] Recover process terminated
> I0828 21:21:46.242501 27645 log.cpp:656] Attempting to start the writer
> I0828 21:21:46.243247 27645 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I0828 21:21:46.253456 27645 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 9.95472ms
> I0828 21:21:46.253955 27645 replica.cpp:342] Persisted promised to 1
> I0828 21:21:46.254518 27645 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I0828 21:21:46.255234 27641 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I0828 21:21:46.263128 27641 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 7.484042ms
> I0828 21:21:46.263536 27641 replica.cpp:676] Persisted action at 0
> I0828 21:21:46.263806 27641 replica.cpp:508] Replica received write request
> for position 0
> I0828 21:21:46.263834 27641 leveldb.cpp:438] Reading position from leveldb
> took 14063ns
> I0828 21:21:46.276149 27641 leveldb.cpp:343] Persisting action (14 bytes) to
> leveldb took 12.295476ms
> I0828 21:21:46.276178 27641 replica.cpp:676] Persisted action at 0
> I0828 21:21:46.2
[jira] [Assigned] (MESOS-1749) SlaveRecoveryTest.ShutdownSlave is flaky
[
https://issues.apache.org/jira/browse/MESOS-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu reassigned MESOS-1749:
-
Assignee: Jie Yu
> SlaveRecoveryTest.ShutdownSlave is flaky
>
>
> Key: MESOS-1749
> URL: https://issues.apache.org/jira/browse/MESOS-1749
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.20.0
> Environment: ubuntu-13.10-gcc
>Reporter: Jie Yu
>Assignee: Jie Yu
>
> {noformat}
> [ RUN ] SlaveRecoveryTest/0.ShutdownSlave
> Using temporary directory '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS'
> I0828 21:21:46.206990 27625 leveldb.cpp:176] Opened db in 24.461837ms
> I0828 21:21:46.213706 27625 leveldb.cpp:183] Compacted db in 6.021499ms
> I0828 21:21:46.214047 27625 leveldb.cpp:198] Created db iterator in 5566ns
> I0828 21:21:46.214313 27625 leveldb.cpp:204] Seeked to beginning of db in
> 1433ns
> I0828 21:21:46.214515 27625 leveldb.cpp:273] Iterated through 0 keys in the
> db in 723ns
> I0828 21:21:46.214826 27625 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0828 21:21:46.215409 27642 recover.cpp:425] Starting replica recovery
> I0828 21:21:46.215718 27642 recover.cpp:451] Replica is in EMPTY status
> I0828 21:21:46.216264 27642 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I0828 21:21:46.216557 27642 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I0828 21:21:46.216917 27642 recover.cpp:542] Updating replica status to
> STARTING
> I0828 21:21:46.221271 27645 master.cpp:286] Master
> 20140828-212146-16842879-45613-27625 (saucy) started on 127.0.1.1:45613
> I0828 21:21:46.221812 27645 master.cpp:332] Master only allowing
> authenticated frameworks to register
> I0828 21:21:46.222038 27645 master.cpp:337] Master only allowing
> authenticated slaves to register
> I0828 21:21:46.50 27645 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/SlaveRecoveryTest_0_ShutdownSlave_3O5epS/credentials'
> I0828 21:21:46.222585 27645 master.cpp:366] Authorization enabled
> I0828 21:21:46.222885 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 5.596969ms
> I0828 21:21:46.223085 27642 replica.cpp:320] Persisted replica status to
> STARTING
> I0828 21:21:46.223424 27642 recover.cpp:451] Replica is in STARTING status
> I0828 21:21:46.223933 27642 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I0828 21:21:46.224984 27642 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I0828 21:21:46.225385 27642 recover.cpp:542] Updating replica status to VOTING
> I0828 21:21:46.224750 27646 master.cpp:1205] The newly elected leader is
> master@127.0.1.1:45613 with id 20140828-212146-16842879-45613-27625
> I0828 21:21:46.226132 27646 master.cpp:1218] Elected as the leading master!
> I0828 21:21:46.226349 27646 master.cpp:1036] Recovering from registrar
> I0828 21:21:46.226637 27646 registrar.cpp:313] Recovering registrar
> I0828 21:21:46.224473 27641 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I0828 21:21:46.224431 27645 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@127.0.1.1:45613
> I0828 21:21:46.240932 27642 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 15.182422ms
> I0828 21:21:46.241453 27642 replica.cpp:320] Persisted replica status to
> VOTING
> I0828 21:21:46.241926 27643 recover.cpp:556] Successfully joined the Paxos
> group
> I0828 21:21:46.242228 27642 recover.cpp:440] Recover process terminated
> I0828 21:21:46.242501 27645 log.cpp:656] Attempting to start the writer
> I0828 21:21:46.243247 27645 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I0828 21:21:46.253456 27645 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 9.95472ms
> I0828 21:21:46.253955 27645 replica.cpp:342] Persisted promised to 1
> I0828 21:21:46.254518 27645 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I0828 21:21:46.255234 27641 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I0828 21:21:46.263128 27641 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 7.484042ms
> I0828 21:21:46.263536 27641 replica.cpp:676] Persisted action at 0
> I0828 21:21:46.263806 27641 replica.cpp:508] Replica received write request
> for position 0
> I0828 21:21:46.263834 27641 leveldb.cpp:438] Reading position from leveldb
> took 14063ns
> I0828 21:21:46.276149 27641 leveldb.cpp:343] Persisting action (14 bytes) to
> leveldb took 12.295476ms
> I0828 21:21:46.276178 27641 replica.cpp:676] Persisted action at 0
> I0828 21:21:46.276319 27641 replica.cp
[jira] [Updated] (MESOS-1747) Docker image parsing for private repositories
[
https://issues.apache.org/jira/browse/MESOS-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-1747:
--
Fix Version/s: 0.20.1
> Docker image parsing for private repositories
> -
>
> Key: MESOS-1747
> URL: https://issues.apache.org/jira/browse/MESOS-1747
> Project: Mesos
> Issue Type: Bug
> Components: containerization, slave
>Affects Versions: 0.20.0
>Reporter: Don Laidlaw
>Assignee: Timothy Chen
> Labels: docker
> Fix For: 0.20.1
>
>
> You cannot specify a port number for the host of a private docker repository.
> Specified as follows: {noformat}
> "container": {
> "type": "DOCKER",
> "docker": {
> "image": "docker-repo:5000/app-base:v0.1"
> }
> }
> {noformat}
> results in an error:
> {noformat}
> Aug 29 14:33:29 ip-172-16-2-22 mesos-slave[1128]: E0829 14:33:29.487470 1153
> slave.cpp:2484] Container '250e0479-552f-4e6f-81dd-71550e45adae' for executor
> 't1-java.71d50bd1-2f89-11e4-ba9a-0adfe6b11716' of framework
> '20140829-121838-184684716-5050-1177-' failed to start:Not expecting
> multiple ':' in image: docker-repo:5000/app-base:v0.1
> {noformat}
> The message indicates only one colon character is allowed, but to supply a
> port number for a private docker repository host you need to have two colons.
> Also if you use a '-' character in a host name you also get an error:
> {noformat}
> Invalid namespace name (docker-repo), only [a-z0-9_] are allowed, size
> between 4 and 30
> {noformat}
> The hostname parts should not be limited to [a-z0-9_].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1747) Docker image parsing for private repositories
[
https://issues.apache.org/jira/browse/MESOS-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Chen updated MESOS-1747:
Labels: docker (was: )
> Docker image parsing for private repositories
> -
>
> Key: MESOS-1747
> URL: https://issues.apache.org/jira/browse/MESOS-1747
> Project: Mesos
> Issue Type: Bug
> Components: containerization, slave
>Affects Versions: 0.20.0
>Reporter: Don Laidlaw
>Assignee: Timothy Chen
> Labels: docker
>
> You cannot specify a port number for the host of a private docker repository.
> Specified as follows: {noformat}
> "container": {
> "type": "DOCKER",
> "docker": {
> "image": "docker-repo:5000/app-base:v0.1"
> }
> }
> {noformat}
> results in an error:
> {noformat}
> Aug 29 14:33:29 ip-172-16-2-22 mesos-slave[1128]: E0829 14:33:29.487470 1153
> slave.cpp:2484] Container '250e0479-552f-4e6f-81dd-71550e45adae' for executor
> 't1-java.71d50bd1-2f89-11e4-ba9a-0adfe6b11716' of framework
> '20140829-121838-184684716-5050-1177-' failed to start:Not expecting
> multiple ':' in image: docker-repo:5000/app-base:v0.1
> {noformat}
> The message indicates only one colon character is allowed, but to supply a
> port number for a private docker repository host you need to have two colons.
> Also if you use a '-' character in a host name you also get an error:
> {noformat}
> Invalid namespace name (docker-repo), only [a-z0-9_] are allowed, size
> between 4 and 30
> {noformat}
> The hostname parts should not be limited to [a-z0-9_].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1747) Docker image parsing for private repositories
[
https://issues.apache.org/jira/browse/MESOS-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117583#comment-14117583
]
Timothy Chen commented on MESOS-1747:
-
For 0.20.0 you can specify a private repository but not with a port
(my-private-repo/image:tag)
There is a fix in master now that allows private repositories with port
information.
About the '-' character, I don't do anything special checking for this as your
image is directly passed to Docker CLI, so the error message you see is
directly from the Docker CLI itself which Docker doesn't allow you to.
> Docker image parsing for private repositories
> -
>
> Key: MESOS-1747
> URL: https://issues.apache.org/jira/browse/MESOS-1747
> Project: Mesos
> Issue Type: Bug
> Components: containerization, slave
>Affects Versions: 0.20.0
>Reporter: Don Laidlaw
>Assignee: Timothy Chen
> Labels: docker
>
> You cannot specify a port number for the host of a private docker repository.
> Specified as follows: {noformat}
> "container": {
> "type": "DOCKER",
> "docker": {
> "image": "docker-repo:5000/app-base:v0.1"
> }
> }
> {noformat}
> results in an error:
> {noformat}
> Aug 29 14:33:29 ip-172-16-2-22 mesos-slave[1128]: E0829 14:33:29.487470 1153
> slave.cpp:2484] Container '250e0479-552f-4e6f-81dd-71550e45adae' for executor
> 't1-java.71d50bd1-2f89-11e4-ba9a-0adfe6b11716' of framework
> '20140829-121838-184684716-5050-1177-' failed to start:Not expecting
> multiple ':' in image: docker-repo:5000/app-base:v0.1
> {noformat}
> The message indicates only one colon character is allowed, but to supply a
> port number for a private docker repository host you need to have two colons.
> Also if you use a '-' character in a host name you also get an error:
> {noformat}
> Invalid namespace name (docker-repo), only [a-z0-9_] are allowed, size
> between 4 and 30
> {noformat}
> The hostname parts should not be limited to [a-z0-9_].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MESOS-1747) Docker image parsing for private repositories
[
https://issues.apache.org/jira/browse/MESOS-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Chen resolved MESOS-1747.
-
Resolution: Fixed
> Docker image parsing for private repositories
> -
>
> Key: MESOS-1747
> URL: https://issues.apache.org/jira/browse/MESOS-1747
> Project: Mesos
> Issue Type: Bug
> Components: containerization, slave
>Affects Versions: 0.20.0
>Reporter: Don Laidlaw
>Assignee: Timothy Chen
> Labels: docker
>
> You cannot specify a port number for the host of a private docker repository.
> Specified as follows: {noformat}
> "container": {
> "type": "DOCKER",
> "docker": {
> "image": "docker-repo:5000/app-base:v0.1"
> }
> }
> {noformat}
> results in an error:
> {noformat}
> Aug 29 14:33:29 ip-172-16-2-22 mesos-slave[1128]: E0829 14:33:29.487470 1153
> slave.cpp:2484] Container '250e0479-552f-4e6f-81dd-71550e45adae' for executor
> 't1-java.71d50bd1-2f89-11e4-ba9a-0adfe6b11716' of framework
> '20140829-121838-184684716-5050-1177-' failed to start:Not expecting
> multiple ':' in image: docker-repo:5000/app-base:v0.1
> {noformat}
> The message indicates only one colon character is allowed, but to supply a
> port number for a private docker repository host you need to have two colons.
> Also if you use a '-' character in a host name you also get an error:
> {noformat}
> Invalid namespace name (docker-repo), only [a-z0-9_] are allowed, size
> between 4 and 30
> {noformat}
> The hostname parts should not be limited to [a-z0-9_].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1007) Python framework unable to parse framework messages
[ https://issues.apache.org/jira/browse/MESOS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117567#comment-14117567 ] Till Toenshoff commented on MESOS-1007: --- I am guessing that this specific issue has magically disappeared and we could close this ticket. [~vinodkone] agree? > Python framework unable to parse framework messages > --- > > Key: MESOS-1007 > URL: https://issues.apache.org/jira/browse/MESOS-1007 > Project: Mesos > Issue Type: Bug > Environment: Fedora 20. Cxx11 >Reporter: Vinod Kone > > [ RUN ] ExamplesTest.PythonFramework > Using temporary directory '/tmp/ExamplesTest_PythonFramework_bk0KRb' > WARNING: Logging before InitGoogleLogging() is written to STDERR > I0213 22:15:39.954318 17373 process.cpp:1591] libprocess is initialized on > 192.168.122.164:47130 for 8 cpus > I0213 22:15:39.955761 17373 logging.cpp:140] Logging to STDERR > I0213 22:15:39.959444 17373 master.cpp:240] Master ID: > 2014-02-13-22:15:39-2759502016-47130-17373 Hostname: fedora-20 > I0213 22:15:39.960225 17383 master.cpp:322] Master started on > 192.168.122.164:47130 > I0213 22:15:39.960244 17383 master.cpp:325] Master only allowing > authenticated frameworks to register! > I0213 22:15:39.961699 17387 master.cpp:86] No whitelist given. Advertising > offers for all slaves > I0213 22:15:39.962286 17382 hierarchical_allocator_process.hpp:302] > Initializing hierarchical allocator process with master : > master@192.168.122.164:47130 > I0213 22:15:39.963912 17373 containerizer.cpp:180] Using isolation: > posix/cpu,posix/mem > I0213 22:15:39.965071 17373 containerizer.cpp:180] Using isolation: > posix/cpu,posix/mem > I0213 22:15:39.965754 17384 slave.cpp:112] Slave started on > 1)@192.168.122.164:47130 > I0213 22:15:39.966032 17387 master.cpp:760] The newly elected leader is > master@192.168.122.164:47130 with id > 2014-02-13-22:15:39-2759502016-47130-17373 > I0213 22:15:39.966341 17387 master.cpp:770] Elected as the leading master! > I0213 22:15:39.966227 17384 slave.cpp:122] Slave resources: cpus(*):1; > mem(*):979; disk(*):1001; ports(*):[31000-32000] > I0213 22:15:39.967811 17384 slave.cpp:150] Slave hostname: fedora-20 > I0213 22:15:39.967828 17384 slave.cpp:151] Slave checkpoint: true > I0213 22:15:39.968070 17384 state.cpp:33] Recovering state from > '/tmp/mesos-KG9dIs/0/meta' > I0213 22:15:39.968147 17384 status_update_manager.cpp:188] Recovering status > update manager > I0213 22:15:39.968200 17384 mesos_containerizer.cpp:137] Recovering > containerizer > I0213 22:15:39.969071 17384 slave.cpp:2670] Finished recovery > I0213 22:15:39.969290 17384 slave.cpp:397] New master detected at > master@192.168.122.164:47130 > I0213 22:15:39.970041 17384 slave.cpp:422] Detecting new master > I0213 22:15:39.970067 17384 status_update_manager.cpp:162] New master > detected at master@192.168.122.164:47130 > I0213 22:15:39.970116 17384 master.cpp:1840] Attempting to register slave on > fedora-20 at slave(1)@192.168.122.164:47130 > I0213 22:15:39.970130 17384 master.cpp:2810] Adding slave > 2014-02-13-22:15:39-2759502016-47130-17373-0 at fedora-20 with cpus(*):1; > mem(*):979; disk(*):1001; ports(*):[31000-32000] > I0213 22:15:39.970213 17384 slave.cpp:440] Registered with master > master@192.168.122.164:47130; given slave ID > 2014-02-13-22:15:39-2759502016-47130-17373-0 > I0213 22:15:39.970365 17384 slave.cpp:453] Checkpointing SlaveInfo to > '/tmp/mesos-KG9dIs/0/meta/slaves/2014-02-13-22:15:39-2759502016-47130-17373-0/slave.info' > I0213 22:15:39.971178 17382 hierarchical_allocator_process.hpp:445] Added > slave 2014-02-13-22:15:39-2759502016-47130-17373-0 (fedora-20) with > cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] (and cpus(*):1; > mem(*):979; disk(*):1001; ports(*):[31000-32000] available) > I0213 22:15:39.971231 17382 hierarchical_allocator_process.hpp:708] Performed > allocation for slave 2014-02-13-22:15:39-2759502016-47130-17373-0 in 9023ns > I0213 22:15:39.972479 17373 containerizer.cpp:180] Using isolation: > posix/cpu,posix/mem > I0213 22:15:39.973124 17381 slave.cpp:112] Slave started on > 2)@192.168.122.164:47130 > I0213 22:15:39.973276 17381 slave.cpp:122] Slave resources: cpus(*):1; > mem(*):979; disk(*):1001; ports(*):[31000-32000] > I0213 22:15:39.974185 17381 slave.cpp:150] Slave hostname: fedora-20 > I0213 22:15:39.974202 17381 slave.cpp:151] Slave checkpoint: true > I0213 22:15:39.975014 17381 state.cpp:33] Recovering state from > '/tmp/mesos-KG9dIs/1/meta' > I0213 22:15:39.975071 17381 status_update_manager.cpp:188] Recovering status > update manager > I0213 22:15:39.975098 17381 mesos_containerizer.cpp:137] Recovering > containerizer > I0213 22:15:39.975219 17381 slave.cpp:2670] Finished recovery > I0213 22:15:39.976111 17381 slave.cpp:397]
[jira] [Commented] (MESOS-1736) Completed tasks shown as running
[
https://issues.apache.org/jira/browse/MESOS-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117277#comment-14117277
]
Alexander Rukletsov commented on MESOS-1736:
Yep, it looks like a task's status update in {{Master::removeFramework()}}
would suffice. The patch is being tested.
However, stopping the framework launches the executor graceful shutdown
mechanism, that, given [escalation is configurable
|https://issues.apache.org/jira/browse/MESOS-1571], gives the opportunity for
the tasks to finish. If we mark these tasks as killed and move to completed, we
loose the chance to collect the possible finished status. I would propose
either to initiate the hard shutdown for executors in this case, or wait for
the actual task statuses from terminated or killed executors.
> Completed tasks shown as running
>
>
> Key: MESOS-1736
> URL: https://issues.apache.org/jira/browse/MESOS-1736
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.21.0
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>Priority: Minor
> Labels: newbie
>
> When a framework is shutdown by calling {{driver.stop()}} from the scheduler,
> running tasks appear as completed in mesos webui but with RUNNING state.
> {{tasks.json}} and {{state.json}} have the same issue as webui. Slave doesn't
> show any anomalies:
> [log|https://gist.github.com/rukletsov/09e8ddf2ee5d02ab06fe].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
