[jira] [Commented] (MESOS-2636) Segfault in inline TryIP getIP(const std::string hostname, int family)
[ https://issues.apache.org/jira/browse/MESOS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14501347#comment-14501347 ] Evelina Dumitrescu commented on MESOS-2636: --- I appologize for that. I added a comment on the review. Segfault in inline TryIP getIP(const std::string hostname, int family) - Key: MESOS-2636 URL: https://issues.apache.org/jira/browse/MESOS-2636 Project: Mesos Issue Type: Bug Reporter: Chi Zhang Assignee: Chi Zhang Labels: twitter We saw a segfault in production. Attaching the coredump, we see: Core was generated by `/usr/local/sbin/mesos-slave --port=5051 --resources=cpus:23;mem:70298;ports:[31'. Program terminated with signal 11, Segmentation fault. #0 0x7f639867c77e in free () from /lib64/libc.so.6 (gdb) bt #0 0x7f639867c77e in free () from /lib64/libc.so.6 #1 0x7f63986c25d0 in freeaddrinfo () from /lib64/libc.so.6 #2 0x7f6399deeafa in net::getIP (hostname=smf1-azc-03-sr2.prod.twitter.com, family=2) at ./3rdparty/stout/include/stout/net.hpp:201 #3 0x7f6399e1f273 in process::initialize (delegate=Unhandled dwarf expression opcode 0xf3 ) at src/process.cpp:837 #4 0x0042342f in main () -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1921) Design and implement protobuf storage of IP addresses
[
https://issues.apache.org/jira/browse/MESOS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353926#comment-14353926
]
Evelina Dumitrescu commented on MESOS-1921:
---
I think that a better aproach would be to:
- Design an additional protobuffer message inside the MasterInfo message
message IPv6 {
required uint32 s6_addr1 = 1;
required uint32 s6_addr2 = 2;
required uint32 s6_addr3 = 3;
required uint32 s6_addr4 = 4;
}
- Add an optional field of Ipv6 type inside the MasterInfo
- An additional field for the IPv6 hostname will be needed in SlaveInfo, Offer,
ContainerInfo protobuffer messages. The resolved hostnames from the IPv4 and
IPv6 addresses might differ. Moreover, if the hostname cannot be resolved then
a string version of the IP address will be returned)
Design and implement protobuf storage of IP addresses
-
Key: MESOS-1921
URL: https://issues.apache.org/jira/browse/MESOS-1921
Project: Mesos
Issue Type: Task
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
We can use {{bytes}} type or statements like {{repeated uint32 data =
4[packed=true];}}
{{string}} representations might add again some parsing overhead. An
additional field might be necessary to specify the protocol family type
(distinguish between IPv4/IPv6). For example, if we don't specify the family
type we can't distinguish between these Ip addresses in the case of
byte/array representation: 0:0:0:0:0:0:IPV4 and IPv4 (see
http://tools.ietf.org/html/rfc4291#page-10)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1921) Design and implement protobuf storage of IP addresses
[
https://issues.apache.org/jira/browse/MESOS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353926#comment-14353926
]
Evelina Dumitrescu edited comment on MESOS-1921 at 3/10/15 12:06 AM:
-
I think that a better aproach would be to:
- Design an additional protobuffer message inside the MasterInfo message
{noformat}
message IPv6 {
required uint32 s6_addr1 = 1;
required uint32 s6_addr2 = 2;
required uint32 s6_addr3 = 3;
required uint32 s6_addr4 = 4;
}
{noformat}
- Add an optional field of Ipv6 type inside the MasterInfo
- An additional field for the IPv6 hostname will be needed in SlaveInfo, Offer,
ContainerInfo protobuffer messages. The resolved hostnames from the IPv4 and
IPv6 addresses might differ. Moreover, if the hostname cannot be resolved then
a string version of the IP address will be returned)
was (Author: evelinad):
I think that a better aproach would be to:
- Design an additional protobuffer message inside the MasterInfo message
message IPv6 {
required uint32 s6_addr1 = 1;
required uint32 s6_addr2 = 2;
required uint32 s6_addr3 = 3;
required uint32 s6_addr4 = 4;
}
- Add an optional field of Ipv6 type inside the MasterInfo
- An additional field for the IPv6 hostname will be needed in SlaveInfo, Offer,
ContainerInfo protobuffer messages. The resolved hostnames from the IPv4 and
IPv6 addresses might differ. Moreover, if the hostname cannot be resolved then
a string version of the IP address will be returned)
Design and implement protobuf storage of IP addresses
-
Key: MESOS-1921
URL: https://issues.apache.org/jira/browse/MESOS-1921
Project: Mesos
Issue Type: Task
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
We can use {{bytes}} type or statements like {{repeated uint32 data =
4[packed=true];}}
{{string}} representations might add again some parsing overhead. An
additional field might be necessary to specify the protocol family type
(distinguish between IPv4/IPv6). For example, if we don't specify the family
type we can't distinguish between these Ip addresses in the case of
byte/array representation: 0:0:0:0:0:0:IPV4 and IPv4 (see
http://tools.ietf.org/html/rfc4291#page-10)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2450) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents
[ https://issues.apache.org/jira/browse/MESOS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2450: -- Description: The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433 (0x7F01) value, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. (was: The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433 value, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order.) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents Key: MESOS-2450 URL: https://issues.apache.org/jira/browse/MESOS-2450 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433 (0x7F01) value, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2450) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents
[ https://issues.apache.org/jira/browse/MESOS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14346843#comment-14346843 ] Evelina Dumitrescu commented on MESOS-2450: --- https://reviews.apache.org/r/31724/ Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents Key: MESOS-2450 URL: https://issues.apache.org/jira/browse/MESOS-2450 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2450) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents
Evelina Dumitrescu created MESOS-2450: - Summary: Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents Key: MESOS-2450 URL: https://issues.apache.org/jira/browse/MESOS-2450 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2450) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents
[ https://issues.apache.org/jira/browse/MESOS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2450: -- Description: The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433 value, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. (was: The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order.) Hardcoded constants in libprocess should be replaced by their INADDR_XXX equivalents Key: MESOS-2450 URL: https://issues.apache.org/jira/browse/MESOS-2450 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu The 0 and 2130706433 values should be replaced by INADDR_ANY and INADDR_LOOPBACK in network order. Also, instead of the 2130706433 value, the check should have been done against 16777343( the localhost IP address as uint32_t in network byte order ). I tried to print the values for the IP address in process.cpp and saw that the tests only cover the 0 value. Note that despite the IPv6 equivalents(in6addr_any and in6addr_loopback), the INADDR_ANY and INADDR_LOOPBACK constants are in host order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2385) Mesos network isolator tests are broken due to mesos::internal namespace removal
Evelina Dumitrescu created MESOS-2385: - Summary: Mesos network isolator tests are broken due to mesos::internal namespace removal Key: MESOS-2385 URL: https://issues.apache.org/jira/browse/MESOS-2385 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Error log http://pastebin.com/MpiBvR1H -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2244) RoutingTestINETSockets fails
[ https://issues.apache.org/jira/browse/MESOS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2244: -- Environment: Ubuntu 14.10, libnl 3.2.25 kernel version: 3.16.0-23-generic #31-Ubuntu SMP x86_64 was:Ubuntu 14.10, libnl 3.2.25 RoutingTestINETSockets fails - Key: MESOS-2244 URL: https://issues.apache.org/jira/browse/MESOS-2244 Project: Mesos Issue Type: Bug Environment: Ubuntu 14.10, libnl 3.2.25 kernel version: 3.16.0-23-generic #31-Ubuntu SMP x86_64 Reporter: Evelina Dumitrescu Assignee: Chi Zhang [ RUN ] RoutingTest.INETSockets *** stack smashing detected ***: /home/evelina/mesos2/mesos/build/src/.libs/lt-mesos-tests terminated *** Aborted at 1421895912 (unix time) try date -d @1421895912 if you are using GNU date *** PC: @ 0x7f3566460d27 (unknown) *** SIGABRT (@0x3e81633) received by PID 5683 (TID 0x7f356c53a7c0) from PID 5683; stack trace: *** @ 0x7f35667fec90 (unknown) @ 0x7f3566460d27 (unknown) @ 0x7f3566462418 (unknown) @ 0x7f35664a29f4 (unknown) @ 0x7f35665365cc (unknown) @ 0x7f3566536570 (unknown) @ 0x7f3566226753 idiagnl_msg_parse @ 0x7f356622678b idiagnl_msg_parser @ 0x7f3565dac4c9 nl_cache_parse @ 0x7f3565dac51b update_msg_parser @ 0x7f3565db1fbf nl_recvmsgs_report @ 0x7f3565db2329 nl_recvmsgs @ 0x7f3565dab9c9 __cache_pickup @ 0x7f3565dac43d nl_cache_pickup @ 0x7f3565dac66e nl_cache_refill @ 0x7f3566226024 idiagnl_msg_alloc_cache @ 0x7f356a95f455 routing::diagnosis::socket::infos() @ 0x114da90 RoutingTest_INETSockets_Test::TestBody() @ 0x11e6957 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e151d testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11c7adb testing::Test::Run() @ 0x11c8253 testing::TestInfo::Run() @ 0x11c87f6 testing::TestCase::Run() @ 0x11cd987 testing::internal::UnitTestImpl::RunAllTests() @ 0x11e7905 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e2304 testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11cc74a testing::UnitTest::Run() @ 0xd7a4ad main @ 0x7f356644bec5 (unknown) @ 0x91ccb9 (unknown) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2244) RoutingTestINETSockets fails
[ https://issues.apache.org/jira/browse/MESOS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14324972#comment-14324972 ] Evelina Dumitrescu commented on MESOS-2244: --- [~chzhcn] yes, this happens each time I run the tests. RoutingTestINETSockets fails - Key: MESOS-2244 URL: https://issues.apache.org/jira/browse/MESOS-2244 Project: Mesos Issue Type: Bug Environment: Ubuntu 14.10, libnl 3.2.25 kernel version: 3.16.0-23-generic #31-Ubuntu SMP x86_64 Reporter: Evelina Dumitrescu Assignee: Chi Zhang [ RUN ] RoutingTest.INETSockets *** stack smashing detected ***: /home/evelina/mesos2/mesos/build/src/.libs/lt-mesos-tests terminated *** Aborted at 1421895912 (unix time) try date -d @1421895912 if you are using GNU date *** PC: @ 0x7f3566460d27 (unknown) *** SIGABRT (@0x3e81633) received by PID 5683 (TID 0x7f356c53a7c0) from PID 5683; stack trace: *** @ 0x7f35667fec90 (unknown) @ 0x7f3566460d27 (unknown) @ 0x7f3566462418 (unknown) @ 0x7f35664a29f4 (unknown) @ 0x7f35665365cc (unknown) @ 0x7f3566536570 (unknown) @ 0x7f3566226753 idiagnl_msg_parse @ 0x7f356622678b idiagnl_msg_parser @ 0x7f3565dac4c9 nl_cache_parse @ 0x7f3565dac51b update_msg_parser @ 0x7f3565db1fbf nl_recvmsgs_report @ 0x7f3565db2329 nl_recvmsgs @ 0x7f3565dab9c9 __cache_pickup @ 0x7f3565dac43d nl_cache_pickup @ 0x7f3565dac66e nl_cache_refill @ 0x7f3566226024 idiagnl_msg_alloc_cache @ 0x7f356a95f455 routing::diagnosis::socket::infos() @ 0x114da90 RoutingTest_INETSockets_Test::TestBody() @ 0x11e6957 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e151d testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11c7adb testing::Test::Run() @ 0x11c8253 testing::TestInfo::Run() @ 0x11c87f6 testing::TestCase::Run() @ 0x11cd987 testing::internal::UnitTestImpl::RunAllTests() @ 0x11e7905 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e2304 testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11cc74a testing::UnitTest::Run() @ 0xd7a4ad main @ 0x7f356644bec5 (unknown) @ 0x91ccb9 (unknown) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2249) Mesos entities should be able to use IPv6 and IPv4 in the same time
[ https://issues.apache.org/jira/browse/MESOS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290105#comment-14290105 ] Evelina Dumitrescu edited comment on MESOS-2249 at 1/23/15 10:20 PM: - Is it worth to implement such algorithm? From what is specified in the RFC, it adds too much overhead(eg: using getaddrinfo each time a request is called, using timers). It's safer to use the IPv4 connection first and as a backup the IPv6 one. was (Author: evelinad): Is it worth to implement such algorithm? From what is specified in the RFC, it adds too much overhead(eg: using getaddrinfo each time a request is called, using timers). Mesos entities should be able to use IPv6 and IPv4 in the same time --- Key: MESOS-2249 URL: https://issues.apache.org/jira/browse/MESOS-2249 Project: Mesos Issue Type: Task Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Each Mesos entity should be able to bind on both Ipv4 and Ipv6 and let the enitity that wants to connect to decide which protocol to use. For example, we can have a slave that wants to use IPv4 and another one that wants to use IPv6, so the master should bind on both. In consequence, I want to propose in process.cpp to have two Node fields, one for each type of endpoint. It might be better that the field for Ipv6 to be an Option, because the stack might not support IPv6(eg: the kernel si not compiled with Ipv6 support). Also, UPID will contain two fields of Node, for each type of protocol. For the HTTP endpoints, whenever a request is done, the entities should try firstly to connect on IPv4 and if the connection fails, to try to use IPv6, or vice versa. We could let the user set up which policy to use. I think in this context it does not matter which protocol is used. I saw this approach in various projects: http://www.perforce.com/perforce/r13.1/manuals/cmdref/env.P4PORT.html (tcp4to6(Attempt to listen/connect to an IPv4 address. If this fails, try IPv6.) and tcp6to4(Attempt to listen/connect to an IPv6 address. If this fails, try IPv4.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2250) Mesos entities should be able to use IPv6 and IPv4 in the same time
Evelina Dumitrescu created MESOS-2250: - Summary: Mesos entities should be able to use IPv6 and IPv4 in the same time Key: MESOS-2250 URL: https://issues.apache.org/jira/browse/MESOS-2250 Project: Mesos Issue Type: Task Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Each Mesos entity should be able to bind on both Ipv4 and Ipv6 and let the enitity that wants to connect to decide which protocol to use. For example, we can have a slave that wants to use IPv4 and another one that wants to use IPv6, so the master should bind on both. In consequence, I want to propose in process.cpp to have two Node fields, one for each type of endpoint. It might be better that the field for Ipv6 to be an Option, because the stack might not support IPv6(eg: the kernel si not compiled with Ipv6 support). Also, UPID will contain two fields of Node, for each type of protocol. For the HTTP endpoints, whenever a request is done, the entities should try firstly to connect on IPv4 and if the connection fails, to try to use IPv6, or vice versa. We could let the user set up which policy to use. I think in this context it does not matter which protocol is used. I saw this approach in various projects: http://www.perforce.com/perforce/r13.1/manuals/cmdref/env.P4PORT.html (tcp4to6(Attempt to listen/connect to an IPv4 address. If this fails, try IPv6.) and tcp6to4(Attempt to listen/connect to an IPv6 address. If this fails, try IPv4.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2244) RoutingTestINETSockets fails
Evelina Dumitrescu created MESOS-2244: - Summary: RoutingTestINETSockets fails Key: MESOS-2244 URL: https://issues.apache.org/jira/browse/MESOS-2244 Project: Mesos Issue Type: Bug Environment: Ubuntu 14.10, libnl 3.2.25 Reporter: Evelina Dumitrescu [ RUN ] RoutingTest.INETSockets *** stack smashing detected ***: /home/evelina/mesos2/mesos/build/src/.libs/lt-mesos-tests terminated *** Aborted at 1421895912 (unix time) try date -d @1421895912 if you are using GNU date *** PC: @ 0x7f3566460d27 (unknown) *** SIGABRT (@0x3e81633) received by PID 5683 (TID 0x7f356c53a7c0) from PID 5683; stack trace: *** @ 0x7f35667fec90 (unknown) @ 0x7f3566460d27 (unknown) @ 0x7f3566462418 (unknown) @ 0x7f35664a29f4 (unknown) @ 0x7f35665365cc (unknown) @ 0x7f3566536570 (unknown) @ 0x7f3566226753 idiagnl_msg_parse @ 0x7f356622678b idiagnl_msg_parser @ 0x7f3565dac4c9 nl_cache_parse @ 0x7f3565dac51b update_msg_parser @ 0x7f3565db1fbf nl_recvmsgs_report @ 0x7f3565db2329 nl_recvmsgs @ 0x7f3565dab9c9 __cache_pickup @ 0x7f3565dac43d nl_cache_pickup @ 0x7f3565dac66e nl_cache_refill @ 0x7f3566226024 idiagnl_msg_alloc_cache @ 0x7f356a95f455 routing::diagnosis::socket::infos() @ 0x114da90 RoutingTest_INETSockets_Test::TestBody() @ 0x11e6957 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e151d testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11c7adb testing::Test::Run() @ 0x11c8253 testing::TestInfo::Run() @ 0x11c87f6 testing::TestCase::Run() @ 0x11cd987 testing::internal::UnitTestImpl::RunAllTests() @ 0x11e7905 testing::internal::HandleSehExceptionsInMethodIfSupported() @ 0x11e2304 testing::internal::HandleExceptionsInMethodIfSupported() @ 0x11cc74a testing::UnitTest::Run() @ 0xd7a4ad main @ 0x7f356644bec5 (unknown) @ 0x91ccb9 (unknown) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225384#comment-14225384
]
Evelina Dumitrescu edited comment on MESOS-1919 at 12/20/14 5:46 AM:
-
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC (shared memory, message
queue) ?
MasterInfo protobuffers
The MasterInfo protobuffers should modify accordingly - a master protobuffer
should have both an ipv4 and an ipv6 field (maybe mark both as optional, but
make sure that at least one of them is set)
Libnl
Use the current create and remove methods also for IPv6 addresses.
Use the same Classifiers, but write different encode/decode functions for
IPv4/ICMP and IPv6/ICMPv6 because the headers differ.
In encodeFilter/decodeFilter, depending on the family of the destinationIP
from the Classifier the encode/decode function for IP/IPv6 shoudl be called
eg: The PortMappingIsolatorProcess class uses a static method create that
returns an instance of the class. The hostIP is passed as a parameter to the
constructor
Resultnet::IP hostIP = net::ip(eth0.get());
The net::ip method returns the first ip address from the eth0 interface. I
want to add a parameter to the ip method specifing the family type of the
address to be returned.
Resultnet::IP hostIP = net::ip(eth0.get(), AF_INET);
Resultnet::IP hostIPv6 = net::ip(eth0.get(), AF_INET6);
In the addHostIPFilters method
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIP.address().ipv4_addr.s_addr), range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIPv6.address().ipv6_addr.s_addr),
range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Replace obsolete functions and define methods in IPAddress to make callsites
AF-independent
Replace functions like gethostbyname with getaddrinfo, I will add such method
in IPAddress that will make the address family transparent to callsites, to
avoid situations like
while ((result = gethostbyname2_r(
host.c_str(), AF_INET, he, temp, length, hep, herrno)) == ERANGE) {
...
}
node.ip.ipv4_addr = *((struct in_addr*) hep-h_addr_list[0]);
Master ID
How is going to be defined the master ID if the master is going to have both
IPV4 and IPv6 addresses?
// The master ID is currently comprised of the current date, the IP
// address and port from self() and the OS PID.
Trystring id =
strings::format(%s-%u-%u-%d, DateUtils::currentDate(),
self().node.ip, self().node.port, getpid());
was (Author: evelinad):
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance
[jira] [Created] (MESOS-2194) Build failure on Ubuntu 14.04, g++ 4.8.2 with the flag --with-network-isolator enabled
Evelina Dumitrescu created MESOS-2194: - Summary: Build failure on Ubuntu 14.04, g++ 4.8.2 with the flag --with-network-isolator enabled Key: MESOS-2194 URL: https://issues.apache.org/jira/browse/MESOS-2194 Project: Mesos Issue Type: Bug Environment: Ubuntu 14.04, g++ 4.8.2 Reporter: Evelina Dumitrescu Priority: Minor I get the following linker error: /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o mesos-local local/mesos_local-main.o libmesos.la -lnl-idiag-3 -lnl-route-3 -lnl-3 -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -lrt libtool: link: g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o .libs/mesos-local local/mesos_local-main.o ./.libs/libmesos.so /usr/lib/libnl-idiag-3.so /usr/lib/libnl-route-3.so /usr/lib/libnl-3.so -lsasl2 /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so /usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libcurl-nss.so -lz -lrt -pthread ./.libs/libmesos.so: undefined reference to `mesos::internal::slave::DEFAULT_EPHEMERAL_PORTS_PER_CONTAINER' collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2194) Build failure on Ubuntu 14.04, g++ 4.8.2 with the flag --with-network-isolator enabled
[ https://issues.apache.org/jira/browse/MESOS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14249194#comment-14249194 ] Evelina Dumitrescu commented on MESOS-2194: --- I realized that this was the problem. I had to remove the build directory. Firsly, I compiled Mesos without the flag. Build failure on Ubuntu 14.04, g++ 4.8.2 with the flag --with-network-isolator enabled --- Key: MESOS-2194 URL: https://issues.apache.org/jira/browse/MESOS-2194 Project: Mesos Issue Type: Bug Environment: Ubuntu 14.04, g++ 4.8.2 Reporter: Evelina Dumitrescu Priority: Minor I get the following linker error: /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o mesos-local local/mesos_local-main.o libmesos.la -lnl-idiag-3 -lnl-route-3 -lnl-3 -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -lrt libtool: link: g++ -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o .libs/mesos-local local/mesos_local-main.o ./.libs/libmesos.so /usr/lib/libnl-idiag-3.so /usr/lib/libnl-route-3.so /usr/lib/libnl-3.so -lsasl2 /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so /usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libcurl-nss.so -lz -lrt -pthread ./.libs/libmesos.so: undefined reference to `mesos::internal::slave::DEFAULT_EPHEMERAL_PORTS_PER_CONTAINER' collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MESOS-1918) Add SockaddrStorage to IP, UPID, etc
[ https://issues.apache.org/jira/browse/MESOS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu closed MESOS-1918. - Resolution: Won't Fix Add SockaddrStorage to IP, UPID, etc Key: MESOS-1918 URL: https://issues.apache.org/jira/browse/MESOS-1918 Project: Mesos Issue Type: Task Components: libprocess Reporter: Dominic Hamon Assignee: Evelina Dumitrescu add a field of type SockaddrStorage in the IP, UPID class other similar classes instead of the ip port fields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2177) Create socket wrappers for different protocol families
Evelina Dumitrescu created MESOS-2177: - Summary: Create socket wrappers for different protocol families Key: MESOS-2177 URL: https://issues.apache.org/jira/browse/MESOS-2177 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2178) Add a method from converting the hostname to an ip address and create initialization wrappers for sockaddr_in and addrinfo
Evelina Dumitrescu created MESOS-2178: - Summary: Add a method from converting the hostname to an ip address and create initialization wrappers for sockaddr_in and addrinfo Key: MESOS-2178 URL: https://issues.apache.org/jira/browse/MESOS-2178 Project: Mesos Issue Type: Task Reporter: Evelina Dumitrescu Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MESOS-1916) Create utility class for storing sockaddr
[
https://issues.apache.org/jira/browse/MESOS-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evelina Dumitrescu closed MESOS-1916.
-
Resolution: Won't Fix
Create utility class for storing sockaddr
-
Key: MESOS-1916
URL: https://issues.apache.org/jira/browse/MESOS-1916
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
{noformat}
// Convenience struct for when you need a |struct sockaddr|.
struct SockaddrStorage {
SockaddrStorage() : addr_len(sizeof(addr_storage)),
addr(reinterpret_caststruct sockaddr*(addr_storage))
{}
SockaddrStorage(const SockaddrStorage other);
void operator=(const SockaddrStorage other);
struct sockaddr_storage addr_storage;
socklen_t addr_len;
struct sockaddr* const addr;
};
SockaddrStorage::SockaddrStorage(const SockaddrStorage other)
: addr_len(other.addr_len),
addr(reinterpret_caststruct sockaddr*(addr_storage)) {
memcpy(addr, other.addr, addr_len);
}
void SockaddrStorage::operator=(const SockaddrStorage other) {
addr_len = other.addr_len;
// addr is already set to this-addr_storage by default ctor.
memcpy(addr, other.addr, addr_len);
}
{noformat}
(shamelessly borrowed from
http://src.chromium.org/svn/trunk/src/net/base/net_util.h/cc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2177) Create socket wrappers for different protocol families
[ https://issues.apache.org/jira/browse/MESOS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2177: -- Description: We should provide non-member functions for connect, bind, accept and getsockname in socket.hpp for creating protocol family abstraction. Create socket wrappers for different protocol families -- Key: MESOS-2177 URL: https://issues.apache.org/jira/browse/MESOS-2177 Project: Mesos Issue Type: Bug Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Priority: Minor Fix For: 0.22.0 We should provide non-member functions for connect, bind, accept and getsockname in socket.hpp for creating protocol family abstraction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225384#comment-14225384
]
Evelina Dumitrescu commented on MESOS-1919:
---
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC (shared memory, message
queue) ?
MasterInfo protobuffers
The MasterInfo protobuffers should modify accordingly - a master protobuffer
should have both an ipv4 and an ipv6 field (maybe mark both as optional, but
make sure that at least one of them is set)
Libnl
Use the current create and remove methods also for IPv6 addresses.
Use the same Classifiers, but write different encode/decode functions for
IPv4/ICMP and IPv6/ICMPv6 because the headers differ.
In encodeFilter/decodeFilter, depending on the family of the destinationIP
from the Classifier the encode/decode function for IP/IPv6 shoudl be called
eg: The PortMappingIsolatorProcess class uses a static method create that
returns an instance of the class. The hostIP is passed as a parameter to the
constructor
Resultnet::IP hostIP = net::ip(eth0.get());
The net::ip method returns the first ip address from the eth0 interface. I
want to add a parameter to the ip method specifing the family type to be
returned.
Resultnet::IP hostIP = net::ip(eth0.get(), AF_INET);
Resultnet::IP hostIPv6 = net::ip(eth0.get(), AF_INET6);
In the addHostIPFilters
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIP.address().ipv4_addr.s_addr), range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Replace obsolete functions and define methods in IPAddress to make callsites
AF-independent
Replace functions like gethostbyname with getaddrinfo, I will add such method
in IPAddress because the call for getaddrinfo is inet-dependant, to avoid
situations like
while ((result = gethostbyname2_r(
host.c_str(), AF_INET, he, temp, length, hep, herrno)) == ERANGE) {
...
}
node.ip.ipv4_addr = *((struct in_addr*) hep-h_addr_list[0]);
Master ID
How is going to be defined the master ID if the master is going to have both
IPV4 and IPv6 addresses?
// The master ID is currently comprised of the current date, the IP
// address and port from self() and the OS PID.
Trystring id =
strings::format(%s-%u-%u-%d, DateUtils::currentDate(),
self().node.ip, self().node.port, getpid());
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225384#comment-14225384
]
Evelina Dumitrescu edited comment on MESOS-1919 at 11/25/14 11:33 PM:
--
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC (shared memory, message
queue) ?
MasterInfo protobuffers
The MasterInfo protobuffers should modify accordingly - a master protobuffer
should have both an ipv4 and an ipv6 field (maybe mark both as optional, but
make sure that at least one of them is set)
Libnl
Use the current create and remove methods also for IPv6 addresses.
Use the same Classifiers, but write different encode/decode functions for
IPv4/ICMP and IPv6/ICMPv6 because the headers differ.
In encodeFilter/decodeFilter, depending on the family of the destinationIP
from the Classifier the encode/decode function for IP/IPv6 shoudl be called
eg: The PortMappingIsolatorProcess class uses a static method create that
returns an instance of the class. The hostIP is passed as a parameter to the
constructor
Resultnet::IP hostIP = net::ip(eth0.get());
The net::ip method returns the first ip address from the eth0 interface. I
want to add a parameter to the ip method specifing the family type to be
returned.
Resultnet::IP hostIP = net::ip(eth0.get(), AF_INET);
Resultnet::IP hostIPv6 = net::ip(eth0.get(), AF_INET6);
In the addHostIPFilters
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIP.address().ipv4_addr.s_addr), range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Replace obsolete functions and define methods in IPAddress to make callsites
AF-independent
Replace functions like gethostbyname with getaddrinfo, I will add such method
in IPAddress that will make the address family transparent to callsites, to
avoid situations like
while ((result = gethostbyname2_r(
host.c_str(), AF_INET, he, temp, length, hep, herrno)) == ERANGE) {
...
}
node.ip.ipv4_addr = *((struct in_addr*) hep-h_addr_list[0]);
Master ID
How is going to be defined the master ID if the master is going to have both
IPV4 and IPv6 addresses?
// The master ID is currently comprised of the current date, the IP
// address and port from self() and the OS PID.
Trystring id =
strings::format(%s-%u-%u-%d, DateUtils::currentDate(),
self().node.ip, self().node.port, getpid());
was (Author: evelinad):
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225384#comment-14225384
]
Evelina Dumitrescu edited comment on MESOS-1919 at 11/25/14 11:38 PM:
--
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
address/netmask(eg: string representation of address/netmask or address and
netmask prefix) to the Mesos internal one(stored in IPAddress).
So, the problems that I want to address are:
Environment variables and libprocess
I think that each instance of libprocess should use both IPv4 and IPv6 address
for binding on(eg process::initialize). This means creating an additional
environment variable LIBPROCESS_IPv6 and let the endpoint that wants to connect
to decide which INET family to use.
Instead of environment variables, why don't we use IPC (shared memory, message
queue) ?
MasterInfo protobuffers
The MasterInfo protobuffers should modify accordingly - a master protobuffer
should have both an ipv4 and an ipv6 field (maybe mark both as optional, but
make sure that at least one of them is set)
Libnl
Use the current create and remove methods also for IPv6 addresses.
Use the same Classifiers, but write different encode/decode functions for
IPv4/ICMP and IPv6/ICMPv6 because the headers differ.
In encodeFilter/decodeFilter, depending on the family of the destinationIP
from the Classifier the encode/decode function for IP/IPv6 shoudl be called
eg: The PortMappingIsolatorProcess class uses a static method create that
returns an instance of the class. The hostIP is passed as a parameter to the
constructor
Resultnet::IP hostIP = net::ip(eth0.get());
The net::ip method returns the first ip address from the eth0 interface. I
want to add a parameter to the ip method specifing the family type of the
address to be returned.
Resultnet::IP hostIP = net::ip(eth0.get(), AF_INET);
Resultnet::IP hostIPv6 = net::ip(eth0.get(), AF_INET6);
In the addHostIPFilters method
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIP.address().ipv4_addr.s_addr), range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Trybool vethToHostLoPublic = filter::ip::create(
veth,
ingress::HANDLE,
ip::Classifier(None(), net::IP(hostIPv6.address().ipv6_addr.s_addr),
range,
None()),
Priority(IP_FILTER_PRIORITY, NORMAL),
action::Redirect(lo));
Replace obsolete functions and define methods in IPAddress to make callsites
AF-independent
Replace functions like gethostbyname with getaddrinfo, I will add such method
in IPAddress that will make the address family transparent to callsites, to
avoid situations like
while ((result = gethostbyname2_r(
host.c_str(), AF_INET, he, temp, length, hep, herrno)) == ERANGE) {
...
}
node.ip.ipv4_addr = *((struct in_addr*) hep-h_addr_list[0]);
Master ID
How is going to be defined the master ID if the master is going to have both
IPV4 and IPv6 addresses?
// The master ID is currently comprised of the current date, the IP
// address and port from self() and the OS PID.
Trystring id =
strings::format(%s-%u-%u-%d, DateUtils::currentDate(),
self().node.ip, self().node.port, getpid());
was (Author: evelinad):
What I have tried so far is to write the struct IPAddress to work with the IPv4
part and integrate it in the code. Further, I want to extend it to IPv6 and
also add IPv6 functionalities in the code(ipv6 fields in protobuffers,
LIBPROCESS_IPV6 environment variable, make libprocess instances in
process:initialize bind on an IPv6 socket). I want to use the IP class be used
only for parsing - converting from different representations of
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222703#comment-14222703
]
Evelina Dumitrescu commented on MESOS-1919:
---
Because this is a more involved change, I thought it would be a good idea to
submit a draft with the temporary progress of the task and receive feedback as
soon as possible.
https://reviews.apache.org/r/28386/
https://reviews.apache.org/r/28387/
https://reviews.apache.org/r/28388/
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203272#comment-14203272
]
Evelina Dumitrescu commented on MESOS-1919:
---
How is it going to be decided the family type for libprocess and mesos?
Currently, in libporcess the default __ip__ is set to 0:
static uint32_t __ip__ = 0;
Should we set the default ip to AF_INET and 0.0.0.0 ?
Should we allow binding on both IPv6 and IPv4 addresses(and make sure that at
least one of them is defined) and let the other endpoint decide which protocol
to use to connect?
This envolves to define another environment variable, LIBPROCESS_IPV6. If this
variables are not defined, when we look for the public IP address call
gethostbyname2 for both AF_INET/AF_INET6?
In this case, which values to store in __ip__ (libprocess has a single variable
to store the IP)?
Otherwise, if we use only one type of protocol family we have to tell
libprocess which type to use, ie by defining an additional environment variable
LIBPROCESS_INET_ FAMILY .
The same thing happends also to mesos in port_mapping. If we decide to use only
a single family type, should we pass a flag to this module?
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2019) Replace the ip and port pairs from the UPID class and process namespace with Node class.
[ https://issues.apache.org/jira/browse/MESOS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2019: -- Summary: Replace the ip and port pairs from the UPID class and process namespace with Node class. (was: Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept.) Replace the ip and port pairs from the UPID class and process namespace with Node class. Key: MESOS-2019 URL: https://issues.apache.org/jira/browse/MESOS-2019 Project: Mesos Issue Type: Improvement Components: framework Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Priority: Minor The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection. A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1956) Add IPv6 ICMPv6 libnl traffic control U32 filters
[ https://issues.apache.org/jira/browse/MESOS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201594#comment-14201594 ] Evelina Dumitrescu commented on MESOS-1956: --- [~wangcong]The part for routing and isolation of containers is going to be rewritten using filters based on IP addresses instead of ephemeral ports? Add IPv6 ICMPv6 libnl traffic control U32 filters --- Key: MESOS-1956 URL: https://issues.apache.org/jira/browse/MESOS-1956 Project: Mesos Issue Type: Task Components: isolation Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu For IPv6, the filtering should be done by source and destination ports, destination IP, destination MAC. For ICMPv6, the filtering should be done by protocol and destination IP. The IPv6/IPv4 difference could be done by the source/destination IP type from the classifier. IPv4 packets with options in the header are currently ignored due to a bug in libnl. It should be investigated if the problem occurs in the case of IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2019) Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept.
[ https://issues.apache.org/jira/browse/MESOS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14191286#comment-14191286 ] Evelina Dumitrescu edited comment on MESOS-2019 at 10/31/14 8:31 PM: - https://reviews.apache.org/r/27446 https://reviews.apache.org/r/27447 was (Author: evelinad): https://reviews.apache.org/r/27413/ Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept. - Key: MESOS-2019 URL: https://issues.apache.org/jira/browse/MESOS-2019 Project: Mesos Issue Type: Improvement Components: framework Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Priority: Minor The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection. A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2019) Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept.
[ https://issues.apache.org/jira/browse/MESOS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2019: -- Component/s: (was: libprocess) Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept. - Key: MESOS-2019 URL: https://issues.apache.org/jira/browse/MESOS-2019 Project: Mesos Issue Type: Improvement Components: framework Reporter: Evelina Dumitrescu Priority: Minor The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection.A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2019) Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept.
[ https://issues.apache.org/jira/browse/MESOS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-2019: -- Description: The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection. A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. was: The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection.A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept. - Key: MESOS-2019 URL: https://issues.apache.org/jira/browse/MESOS-2019 Project: Mesos Issue Type: Improvement Components: framework Reporter: Evelina Dumitrescu Priority: Minor The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection. A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2019) Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept.
[ https://issues.apache.org/jira/browse/MESOS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14191286#comment-14191286 ] Evelina Dumitrescu commented on MESOS-2019: --- https://reviews.apache.org/r/27413/ Rename the Node class in Endpoint and replace the ip and port pairs from the UPID class and process namespace with this concept. - Key: MESOS-2019 URL: https://issues.apache.org/jira/browse/MESOS-2019 Project: Mesos Issue Type: Improvement Components: framework Reporter: Evelina Dumitrescu Priority: Minor The Node class abstracts the endpoint notion: it defines the association of the ip and port for a connection. A node defines more the host(which can have multiple active endpoints). At the moment, the Node class is used to keep a mapping from a socket to the ip port pair in the process namespace. I want to propose to rename this class in Endpoint and also extend its use by replacing the ip port fields from the UPID class and process namespace with this type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184789#comment-14184789
]
Evelina Dumitrescu commented on MESOS-1919:
---
Possible cases where it wouldn't make sense to use
sockaddr_in/sockaddr_in6/sockaddr_storage:
- the IP class and the various situations where it is used:
- libnl Classifiers for ICMP
- libnl routing Rule class
- for getting IPs from interfaces (ie: inline ResultIP ip(const
std::string name))
- Process class - separate methods for getting the ip and port(ie: used in
./src/master/http.cpp, type_utils.cpp, sched.cpp)
- flags and environment variables setting.
The IP abstraction will be used also for the netmask.
I think that the Node class should be left as it is.
IMO, Node actually abstracts the endpoint notion: it defines the association of
the ip port for a connetion.
A node defines more the host(which can have multiple active endpoints).
I want to propose to rename this class in Endpoint and also replace the ip and
port fields from UPID class with this type.
All the IPv6/IPv4 abstraction should be moved into a single class.
This class should be able to work with the SockaddrStorage struct (that will be
useful for the functions that use sockaddr) and with the IPAddress struct(that
will be useful for the situations where only the IP is needed). So far, I have
reffered to this class as IPEndPoint, but the class name should be changed to
something more appropiate: maybe InetHandler(because it handles the
SockaddrStorage and IPAddress structs).
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184789#comment-14184789
]
Evelina Dumitrescu edited comment on MESOS-1919 at 10/27/14 3:44 AM:
-
Possible cases where it wouldn't make sense to use
sockaddr_in/sockaddr_in6/sockaddr_storage:
- the IP class and the various situations where it is used:
-- libnl Classifiers for ICMP
-- libnl routing Rule class
-- for getting IPs from interfaces (ie: inline ResultIP ip(const
std::string name))
- Process class - separate methods for getting the ip and port(ie: used in
./src/master/http.cpp, type_utils.cpp, sched.cpp)
- flags and environment variables setting.
The IP abstraction will be used also for the netmask.
I think that the Node class should be left as it is.
IMO, Node actually abstracts the endpoint notion: it defines the association of
the ip port for a connetion.
A node defines more the host(which can have multiple active endpoints).
I want to propose to rename this class in Endpoint and also replace the ip and
port fields from UPID class with this type.
All the IPv6/IPv4 abstraction should be moved into a single class.
This class should be able to work with the SockaddrStorage struct (that will be
useful for the functions that use sockaddr) and with the IPAddress struct(that
will be useful for the situations where only the IP is needed). So far, I have
reffered to this class as IPEndPoint, but the class name should be changed to
something more appropiate: maybe InetHandler(because it handles the
SockaddrStorage and IPAddress structs).
was (Author: evelinad):
Possible cases where it wouldn't make sense to use
sockaddr_in/sockaddr_in6/sockaddr_storage:
- the IP class and the various situations where it is used:
- libnl Classifiers for ICMP
- libnl routing Rule class
- for getting IPs from interfaces (ie: inline ResultIP ip(const
std::string name))
- Process class - separate methods for getting the ip and port(ie: used in
./src/master/http.cpp, type_utils.cpp, sched.cpp)
- flags and environment variables setting.
The IP abstraction will be used also for the netmask.
I think that the Node class should be left as it is.
IMO, Node actually abstracts the endpoint notion: it defines the association of
the ip port for a connetion.
A node defines more the host(which can have multiple active endpoints).
I want to propose to rename this class in Endpoint and also replace the ip and
port fields from UPID class with this type.
All the IPv6/IPv4 abstraction should be moved into a single class.
This class should be able to work with the SockaddrStorage struct (that will be
useful for the functions that use sockaddr) and with the IPAddress struct(that
will be useful for the situations where only the IP is needed). So far, I have
reffered to this class as IPEndPoint, but the class name should be changed to
something more appropiate: maybe InetHandler(because it handles the
SockaddrStorage and IPAddress structs).
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183448#comment-14183448
]
Evelina Dumitrescu commented on MESOS-1919:
---
After serveral discussions, I have proposed the following structure:
struct IPAddress {
uint8_t family;
union {
struct in_addr ipv4_address;
struct in6_addr ipv6_address;
};
};
Is everybody okay to stick to this representation?
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183448#comment-14183448
]
Evelina Dumitrescu edited comment on MESOS-1919 at 10/24/14 8:55 PM:
-
After serveral discussions, I have proposed the following structure:
{noformat}
struct IPAddress {
uint8_t family;
union {
struct in_addr ipv4_address;
struct in6_addr ipv6_address;
};
};
{noformat}
Is everybody okay to stick to this representation?
was (Author: evelinad):
After serveral discussions, I have proposed the following structure:
struct IPAddress {
uint8_t family;
union {
struct in_addr ipv4_address;
struct in6_addr ipv6_address;
};
};
Is everybody okay to stick to this representation?
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183690#comment-14183690
]
Evelina Dumitrescu commented on MESOS-1919:
---
I wanted to use struct IPAddress only for storage and create all the abstaction
needed in the IPEndPoint class and the callsites will use only the metods from
the IPEndPoint class. It might be better to use this representation because the
networking calls(ie inet_ntop, inet_pton) work with in_addr and in6_addr
structs. Otherwise, we need to convert the vector to this type of structs each
time.
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183709#comment-14183709
]
Evelina Dumitrescu commented on MESOS-1919:
---
[~jmlvanre] Your concern on using the stl vector representation was that the
stl vector will alocate more memory than is needed.
The stl vector initial capacity starts from 0(for the default constructor) and
doubles the allocated memory when reallocation is needed. And for the
particular case of the IPV4 and IPv6 sizes(which have the form of power of two)
memory will not be allocated and then left unused.
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1919) Create IP address abstraction
[
https://issues.apache.org/jira/browse/MESOS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181986#comment-14181986
]
Evelina Dumitrescu edited comment on MESOS-1919 at 10/23/14 9:20 PM:
-
So far have been proposed two ideas:
- __int128_t/__uint128_t types from gcc. Gcc supports this since the 4.6
release.
https://gcc.gnu.org/gcc-4.6/changes.html
- std::vector of unsigned char/integers. If we choose this approach, we could
know easier the family type of the protocol by the size of the vector (eg: IPv4
will have 4 bytes length, IPv6 will have 16).
Which of these options should we decide on ?
was (Author: evelinad):
So far have been proposed two ideas:
- __int128_t/__uint128_t types from gcc. Gcc supports this since the 4.6
release.
https://gcc.gnu.org/gcc-4.6/changes.html
- std::vector of unsigned char. If we choose this approach, we could know
easier the family type of the protocol by the size of the vector (eg: IPv4 will
have 4 bytes length, IPv6 will have 16).
Which of these options should we decide on ?
Create IP address abstraction
-
Key: MESOS-1919
URL: https://issues.apache.org/jira/browse/MESOS-1919
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Dominic Hamon
Assignee: Evelina Dumitrescu
Priority: Minor
in the code many functions need only the ip address to be passed as a
parameter. I don't think it would be desirable to use a struct
SockaddrStorage (MESOS-1916).
Consider using a {{std::vectorunsigned char}} (see {{typedef
std::vectorunsigned char IPAddressNumber;}} in the Chromium project)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-1956) Add IPv6 ICMPv6 libnl traffic control U32 filters
Evelina Dumitrescu created MESOS-1956: - Summary: Add IPv6 ICMPv6 libnl traffic control U32 filters Key: MESOS-1956 URL: https://issues.apache.org/jira/browse/MESOS-1956 Project: Mesos Issue Type: Task Components: isolation Reporter: Evelina Dumitrescu For IPv6, the filtering should be done by source and destination ports, destination IP, destination MAC. For ICMPv6, the filtering should be done by protocol and destination IP. The IPv6/IPv4 difference could be done by the source/destination IP type from the classifier. IPv4 packets with options in the header are currently ignored due to a bug in libnl. It should be investigated if the problem occurs in the case of IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1957) Port mapping IPv6 support
Evelina Dumitrescu created MESOS-1957: - Summary: Port mapping IPv6 support Key: MESOS-1957 URL: https://issues.apache.org/jira/browse/MESOS-1957 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu It has to be investigated the best way for the port mapping module to know that it uses and IPv6 environment. Possible ways are: - by the IP address of the host eth0 - passing a flag A question that needs special attention is what should be done if eth0 or lo have both IPv4 and IPv6 addresses. Also, it may be necessary to keep separate counters for IPv4/IPv6. The LOOPBACK_IP is currently hardcoded to 127.0.0.1/8. In the case of an IPv6 environment, owing to the fact that this variable is used only for services that run on a single node and might not be used in routing scenarios, it should be investigated keeping this value or adding another variable LOOPBACK_IPv6. This will affect the add/removeContainerIPFilters and add/removeHostIPFilters methods. Socket diagnosis needs to be done also for AF_INET6 family. IPv6 disabling needs to be removed (eg: script echo 1 /proc/sys/net/ipv6/conf/all/disable_ipv6\n; from PortMappingIsolatorProcess::scripts). For IPv4 some functionalities are disabled(eg: 'rp_filter' and 'send_redirects' for lo) or enabled(eg: 'route_localnet' and 'accept_local' for lo). Other ones are inherited by the container from the host(eg: tcp_rmem, tcp_wmem). The ephemeral port ranges can be different between IPv6 and IPv4(eg: os::read(/proc/sys/net/ipv4/ip_local_port_range);). The same thing should be done for IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1957) Port mapping IPv6 support
[ https://issues.apache.org/jira/browse/MESOS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1957: -- Description: It has to be investigated the best way for the port mapping module to know that it uses and IPv6 environment. Possible ways are: - by the IP address of the host eth0 - passing a flag A question that needs special attention is what should be done if eth0 or lo have both IPv4 and IPv6 addresses. Also, it may be necessary to keep separate counters for IPv4/IPv6. The LOOPBACK_IP is currently hardcoded to 127.0.0.1/8. In the case of an IPv6 environment, owing to the fact that this variable is used only for services that run on a single node and might not be used in routing scenarios, it should be investigated keeping this value or adding another variable LOOPBACK_IPv6. This will affect the add/removeContainerIPFilters and add/removeHostIPFilters methods. Socket diagnosis needs to be done also for AF_INET6 family. IPv6 disabling needs to be removed (eg: script echo 1 /proc/sys/net/ipv6/conf/all/disable_ipv6\n; from PortMappingIsolatorProcess::scripts). For IPv4 some functionalities are disabled(eg: 'rp_filter' and 'send_redirects' for lo) or enabled(eg: 'route_localnet' and 'accept_local' for lo). Other ones are inherited by the container from the host(eg: tcp_rmem, tcp_wmem). The ephemeral port ranges can be different between IPv6 and IPv4(eg: os::read(/proc/sys/net/ipv4/ip_local_port_range); ). The same thing should be done for IPv6. was: It has to be investigated the best way for the port mapping module to know that it uses and IPv6 environment. Possible ways are: - by the IP address of the host eth0 - passing a flag A question that needs special attention is what should be done if eth0 or lo have both IPv4 and IPv6 addresses. Also, it may be necessary to keep separate counters for IPv4/IPv6. The LOOPBACK_IP is currently hardcoded to 127.0.0.1/8. In the case of an IPv6 environment, owing to the fact that this variable is used only for services that run on a single node and might not be used in routing scenarios, it should be investigated keeping this value or adding another variable LOOPBACK_IPv6. This will affect the add/removeContainerIPFilters and add/removeHostIPFilters methods. Socket diagnosis needs to be done also for AF_INET6 family. IPv6 disabling needs to be removed (eg: script echo 1 /proc/sys/net/ipv6/conf/all/disable_ipv6\n; from PortMappingIsolatorProcess::scripts). For IPv4 some functionalities are disabled(eg: 'rp_filter' and 'send_redirects' for lo) or enabled(eg: 'route_localnet' and 'accept_local' for lo). Other ones are inherited by the container from the host(eg: tcp_rmem, tcp_wmem). The ephemeral port ranges can be different between IPv6 and IPv4(eg: os::read(/proc/sys/net/ipv4/ip_local_port_range);). The same thing should be done for IPv6. Port mapping IPv6 support - Key: MESOS-1957 URL: https://issues.apache.org/jira/browse/MESOS-1957 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu It has to be investigated the best way for the port mapping module to know that it uses and IPv6 environment. Possible ways are: - by the IP address of the host eth0 - passing a flag A question that needs special attention is what should be done if eth0 or lo have both IPv4 and IPv6 addresses. Also, it may be necessary to keep separate counters for IPv4/IPv6. The LOOPBACK_IP is currently hardcoded to 127.0.0.1/8. In the case of an IPv6 environment, owing to the fact that this variable is used only for services that run on a single node and might not be used in routing scenarios, it should be investigated keeping this value or adding another variable LOOPBACK_IPv6. This will affect the add/removeContainerIPFilters and add/removeHostIPFilters methods. Socket diagnosis needs to be done also for AF_INET6 family. IPv6 disabling needs to be removed (eg: script echo 1 /proc/sys/net/ipv6/conf/all/disable_ipv6\n; from PortMappingIsolatorProcess::scripts). For IPv4 some functionalities are disabled(eg: 'rp_filter' and 'send_redirects' for lo) or enabled(eg: 'route_localnet' and 'accept_local' for lo). Other ones are inherited by the container from the host(eg: tcp_rmem, tcp_wmem). The ephemeral port ranges can be different between IPv6 and IPv4(eg: os::read(/proc/sys/net/ipv4/ip_local_port_range); ). The same thing should be done for IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1958) Intercontainer IPv6 routing table
[ https://issues.apache.org/jira/browse/MESOS-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1958: -- Description: TryvectorRule table() should dump routes for AF_INET6 (maybe use AF_UNSPEC ?) was: TryvectorRule table() dump also routes for AF_INET6 (maybe use AF_UNSPEC ?) Intercontainer IPv6 routing table - Key: MESOS-1958 URL: https://issues.apache.org/jira/browse/MESOS-1958 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu TryvectorRule table() should dump routes for AF_INET6 (maybe use AF_UNSPEC ?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1959) Link flag, MAC, MTU setting for IPv6
Evelina Dumitrescu created MESOS-1959: - Summary: Link flag, MAC, MTU setting for IPv6 Key: MESOS-1959 URL: https://issues.apache.org/jira/browse/MESOS-1959 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1959) Link flag, MAC, MTU setting for IPv6
[ https://issues.apache.org/jira/browse/MESOS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1959: -- Description: Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). was:Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). Link flag, MAC, MTU setting for IPv6 Key: MESOS-1959 URL: https://issues.apache.org/jira/browse/MESOS-1959 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1956) Add IPv6 ICMPv6 libnl traffic control U32 filters
[ https://issues.apache.org/jira/browse/MESOS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1956: - Assignee: Evelina Dumitrescu Add IPv6 ICMPv6 libnl traffic control U32 filters --- Key: MESOS-1956 URL: https://issues.apache.org/jira/browse/MESOS-1956 Project: Mesos Issue Type: Task Components: isolation Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu For IPv6, the filtering should be done by source and destination ports, destination IP, destination MAC. For ICMPv6, the filtering should be done by protocol and destination IP. The IPv6/IPv4 difference could be done by the source/destination IP type from the classifier. IPv4 packets with options in the header are currently ignored due to a bug in libnl. It should be investigated if the problem occurs in the case of IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1958) Intercontainer IPv6 routing table
[ https://issues.apache.org/jira/browse/MESOS-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1958: - Assignee: Evelina Dumitrescu Intercontainer IPv6 routing table - Key: MESOS-1958 URL: https://issues.apache.org/jira/browse/MESOS-1958 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu TryvectorRule table() should dump routes for AF_INET6 (maybe use AF_UNSPEC ?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1957) Port mapping IPv6 support
[ https://issues.apache.org/jira/browse/MESOS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1957: - Assignee: Evelina Dumitrescu Port mapping IPv6 support - Key: MESOS-1957 URL: https://issues.apache.org/jira/browse/MESOS-1957 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu It has to be investigated the best way for the port mapping module to know that it uses and IPv6 environment. Possible ways are: - by the IP address of the host eth0 - passing a flag A question that needs special attention is what should be done if eth0 or lo have both IPv4 and IPv6 addresses. Also, it may be necessary to keep separate counters for IPv4/IPv6. The LOOPBACK_IP is currently hardcoded to 127.0.0.1/8. In the case of an IPv6 environment, owing to the fact that this variable is used only for services that run on a single node and might not be used in routing scenarios, it should be investigated keeping this value or adding another variable LOOPBACK_IPv6. This will affect the add/removeContainerIPFilters and add/removeHostIPFilters methods. Socket diagnosis needs to be done also for AF_INET6 family. IPv6 disabling needs to be removed (eg: script echo 1 /proc/sys/net/ipv6/conf/all/disable_ipv6\n; from PortMappingIsolatorProcess::scripts). For IPv4 some functionalities are disabled(eg: 'rp_filter' and 'send_redirects' for lo) or enabled(eg: 'route_localnet' and 'accept_local' for lo). Other ones are inherited by the container from the host(eg: tcp_rmem, tcp_wmem). The ephemeral port ranges can be different between IPv6 and IPv4(eg: os::read(/proc/sys/net/ipv4/ip_local_port_range); ). The same thing should be done for IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1959) Link flag, MAC and MTU setting for IPv6
[ https://issues.apache.org/jira/browse/MESOS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1959: -- Summary: Link flag, MAC and MTU setting for IPv6 (was: Link flag, MAC, MTU setting for IPv6) Link flag, MAC and MTU setting for IPv6 --- Key: MESOS-1959 URL: https://issues.apache.org/jira/browse/MESOS-1959 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Assignee: Evelina Dumitrescu Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1959) Link flag, MAC, MTU setting for IPv6
[ https://issues.apache.org/jira/browse/MESOS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1959: -- Shepherd: Dominic Hamon Link flag, MAC, MTU setting for IPv6 Key: MESOS-1959 URL: https://issues.apache.org/jira/browse/MESOS-1959 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Evelina Dumitrescu Libnl has some issues with virtual devices and rtnl_link_change; therefore a socket is created artificially( int fd = ::socket(AF_INET, SOCK_STREAM, 0);)and ioctl is used to set the flags/ MAC address/ MTU. We should investigate if this socket type matters. If yes, it can be set to AF_UNSPEC or the socket creation should be done depending on the family type of the link(eg: use rtnl_link_get_family/nl_addr_ger_family). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1872) Cleanup right angle bracket in the code base.
[
https://issues.apache.org/jira/browse/MESOS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168288#comment-14168288
]
Evelina Dumitrescu edited comment on MESOS-1872 at 10/15/14 6:08 PM:
-
Review
https://reviews.apache.org/r/26605/
https://reviews.apache.org/r/26740/
https://reviews.apache.org/r/26741/
https://reviews.apache.org/r/26739/
was (Author: evelinad):
Review
https://reviews.apache.org/r/26605/
Cleanup right angle bracket in the code base.
-
Key: MESOS-1872
URL: https://issues.apache.org/jira/browse/MESOS-1872
Project: Mesos
Issue Type: Bug
Reporter: Jie Yu
Assignee: Evelina Dumitrescu
Labels: c++11, newbie
As we start to use c++11 style right angle brackets ('' instead of ' '):
https://reviews.apache.org/r/25861
We should do a sweep in our code base to make it consistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1872) Cleanup right angle bracket in the code base.
[
https://issues.apache.org/jira/browse/MESOS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168288#comment-14168288
]
Evelina Dumitrescu commented on MESOS-1872:
---
Review
https://reviews.apache.org/r/26605/
Cleanup right angle bracket in the code base.
-
Key: MESOS-1872
URL: https://issues.apache.org/jira/browse/MESOS-1872
Project: Mesos
Issue Type: Bug
Reporter: Jie Yu
Assignee: Evelina Dumitrescu
Labels: c++11, newbie
As we start to use c++11 style right angle brackets ('' instead of ' '):
https://reviews.apache.org/r/25861
We should do a sweep in our code base to make it consistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1835) Check for IP address being localhost not platform independent
[ https://issues.apache.org/jira/browse/MESOS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14157954#comment-14157954 ] Evelina Dumitrescu commented on MESOS-1835: --- So the check should be done against 16777343( the localhost IP address as uint32_t in network byte order ), regardless of endianess? Check for IP address being localhost not platform independent - Key: MESOS-1835 URL: https://issues.apache.org/jira/browse/MESOS-1835 Project: Mesos Issue Type: Bug Components: libprocess Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu In process::initialize() [3rdparty/src/libprocess/process.cpp], check for __ip__ for localhost (127.0.0.1) is done by checking if __ip__ == 2130706433. However, it could be either 2130706433 or 16777343 depending on endianness. This check should succeed independent of the endianness, so would be good to do a 'inet_ntop' and then compare against the string for 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1835) Check for IP address being localhost not platform independent
[ https://issues.apache.org/jira/browse/MESOS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14157954#comment-14157954 ] Evelina Dumitrescu edited comment on MESOS-1835 at 10/3/14 3:15 PM: So the check should be done against 16777343( the localhost IP address as uint32_t in network byte order ), regardless of the machine's endianess? was (Author: evelinad): So the check should be done against 16777343( the localhost IP address as uint32_t in network byte order ), regardless of endianess? Check for IP address being localhost not platform independent - Key: MESOS-1835 URL: https://issues.apache.org/jira/browse/MESOS-1835 Project: Mesos Issue Type: Bug Components: libprocess Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu In process::initialize() [3rdparty/src/libprocess/process.cpp], check for __ip__ for localhost (127.0.0.1) is done by checking if __ip__ == 2130706433. However, it could be either 2130706433 or 16777343 depending on endianness. This check should succeed independent of the endianness, so would be good to do a 'inet_ntop' and then compare against the string for 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1835) Check for IP address being localhost not platform independent
[ https://issues.apache.org/jira/browse/MESOS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158713#comment-14158713 ] Evelina Dumitrescu commented on MESOS-1835: --- I've done a small testing program and saw that getsockname uses network order. In the code only the port number is converted in host order: __ip__ = addr.sin_addr.s_addr; __port__ = ntohs(addr.sin_port); Check for IP address being localhost not platform independent - Key: MESOS-1835 URL: https://issues.apache.org/jira/browse/MESOS-1835 Project: Mesos Issue Type: Bug Components: libprocess Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu In process::initialize() [3rdparty/src/libprocess/process.cpp], check for __ip__ for localhost (127.0.0.1) is done by checking if __ip__ == 2130706433. However, it could be either 2130706433 or 16777343 depending on endianness. This check should succeed independent of the endianness, so would be good to do a 'inet_ntop' and then compare against the string for 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1552) Mesos javadoc should include .proto javadoc
[ https://issues.apache.org/jira/browse/MESOS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1552: - Assignee: Evelina Dumitrescu Mesos javadoc should include .proto javadoc --- Key: MESOS-1552 URL: https://issues.apache.org/jira/browse/MESOS-1552 Project: Mesos Issue Type: Story Components: documentation, java api Reporter: Kevin Sweeney Assignee: Evelina Dumitrescu The Java API documentation on the website (http://mesos.apache.org/api/latest/java/) should include protobuf documentation. protoc automatically generates javadoc based on comments in the .proto so this should be a matter of wiring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1552) Mesos javadoc should include .proto javadoc
[ https://issues.apache.org/jira/browse/MESOS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu updated MESOS-1552: -- Assignee: (was: Evelina Dumitrescu) Mesos javadoc should include .proto javadoc --- Key: MESOS-1552 URL: https://issues.apache.org/jira/browse/MESOS-1552 Project: Mesos Issue Type: Story Components: documentation, java api Reporter: Kevin Sweeney The Java API documentation on the website (http://mesos.apache.org/api/latest/java/) should include protobuf documentation. protoc automatically generates javadoc based on comments in the .proto so this should be a matter of wiring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1835) Check for IP address being localhost not platform independent
[ https://issues.apache.org/jira/browse/MESOS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155782#comment-14155782 ] Evelina Dumitrescu commented on MESOS-1835: --- Review https://reviews.apache.org/r/26253/ Should I write additional tests? Check for IP address being localhost not platform independent - Key: MESOS-1835 URL: https://issues.apache.org/jira/browse/MESOS-1835 Project: Mesos Issue Type: Bug Components: libprocess Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu In process::initialize() [3rdparty/src/libprocess/process.cpp], check for __ip__ for localhost (127.0.0.1) is done by checking if __ip__ == 2130706433. However, it could be either 2130706433 or 16777343 depending on endianness. This check should succeed independent of the endianness, so would be good to do a 'inet_ntop' and then compare against the string for 127.0.0.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1834) Default port for mesos is 5050, but documentation states it as 5051
[ https://issues.apache.org/jira/browse/MESOS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1834: - Assignee: Evelina Dumitrescu Default port for mesos is 5050, but documentation states it as 5051 --- Key: MESOS-1834 URL: https://issues.apache.org/jira/browse/MESOS-1834 Project: Mesos Issue Type: Bug Components: documentation Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu Priority: Minor docs/configuration.md states the following: --port=VALUE Port to listen on (default: 5051) but the default port is 5050 instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1834) Default port for mesos is 5050, but documentation states it as 5051
[ https://issues.apache.org/jira/browse/MESOS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155824#comment-14155824 ] Evelina Dumitrescu commented on MESOS-1834: --- Review https://reviews.apache.org/r/26253/ Default port for mesos is 5050, but documentation states it as 5051 --- Key: MESOS-1834 URL: https://issues.apache.org/jira/browse/MESOS-1834 Project: Mesos Issue Type: Bug Components: documentation Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu Priority: Minor docs/configuration.md states the following: --port=VALUE Port to listen on (default: 5051) but the default port is 5050 instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1834) Default port for mesos is 5050, but documentation states it as 5051
[ https://issues.apache.org/jira/browse/MESOS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155824#comment-14155824 ] Evelina Dumitrescu edited comment on MESOS-1834 at 10/1/14 11:56 PM: - Review https://reviews.apache.org/r/26254/ was (Author: evelinad): Review https://reviews.apache.org/r/26253/ Default port for mesos is 5050, but documentation states it as 5051 --- Key: MESOS-1834 URL: https://issues.apache.org/jira/browse/MESOS-1834 Project: Mesos Issue Type: Bug Components: documentation Affects Versions: 0.20.1 Reporter: Anindya Sinha Assignee: Evelina Dumitrescu Priority: Minor docs/configuration.md states the following: --port=VALUE Port to listen on (default: 5051) but the default port is 5050 instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1269) Log id of the executor sending status update to the slave
[ https://issues.apache.org/jira/browse/MESOS-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1269: - Assignee: Evelina Dumitrescu Log id of the executor sending status update to the slave - Key: MESOS-1269 URL: https://issues.apache.org/jira/browse/MESOS-1269 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Assignee: Evelina Dumitrescu Priority: Minor Currently we log the pid of the sending executor. It would be great to instead (or in addition) log the executor id of the sender to allow for easier debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1506) Update documentation/flags regarding new default hostname semantics
[ https://issues.apache.org/jira/browse/MESOS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153530#comment-14153530 ] Evelina Dumitrescu commented on MESOS-1506: --- https://reviews.apache.org/r/26185/ Update documentation/flags regarding new default hostname semantics --- Key: MESOS-1506 URL: https://issues.apache.org/jira/browse/MESOS-1506 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 0.18.0, 0.19.0, 0.20.0 Reporter: Vinod Kone Assignee: Vidyu Rani https://issues.apache.org/jira/browse/MESOS-672 was committed in 0.18.0 which fixed redirection of WebUI. Included in this fix is https://reviews.apache.org/r/17573/ which changed how the SlaveInfo.hostname is calculated when --hostname is not provided. Specifically, slave now deduces the hostname from --ip flag when --hostname is not provided. We should update the slave/master flags and documentation (http://mesos.apache.org/documentation/latest/configuration/) reflecting this change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1506) Update documentation/flags regarding new default hostname semantics
[ https://issues.apache.org/jira/browse/MESOS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1506: - Assignee: Evelina Dumitrescu (was: Vidyu Rani) Update documentation/flags regarding new default hostname semantics --- Key: MESOS-1506 URL: https://issues.apache.org/jira/browse/MESOS-1506 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 0.18.0, 0.19.0, 0.20.0 Reporter: Vinod Kone Assignee: Evelina Dumitrescu https://issues.apache.org/jira/browse/MESOS-672 was committed in 0.18.0 which fixed redirection of WebUI. Included in this fix is https://reviews.apache.org/r/17573/ which changed how the SlaveInfo.hostname is calculated when --hostname is not provided. Specifically, slave now deduces the hostname from --ip flag when --hostname is not provided. We should update the slave/master flags and documentation (http://mesos.apache.org/documentation/latest/configuration/) reflecting this change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-1552) Mesos javadoc should include .proto javadoc
[ https://issues.apache.org/jira/browse/MESOS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evelina Dumitrescu reassigned MESOS-1552: - Assignee: Evelina Dumitrescu Mesos javadoc should include .proto javadoc --- Key: MESOS-1552 URL: https://issues.apache.org/jira/browse/MESOS-1552 Project: Mesos Issue Type: Story Components: documentation, java api Reporter: Kevin Sweeney Assignee: Evelina Dumitrescu The Java API documentation on the website (http://mesos.apache.org/api/latest/java/) should include protobuf documentation. protoc automatically generates javadoc based on comments in the .proto so this should be a matter of wiring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1506) Update documentation/flags regarding new default hostname semantics
[ https://issues.apache.org/jira/browse/MESOS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14152388#comment-14152388 ] Evelina Dumitrescu commented on MESOS-1506: --- I think that there might be an inconsistency in getHostname. If the hostname cannot be resolved, then a string version of the IP address should be returned. Instead, if getnameinfo fails, an error string corresponding to the error code is returned by gai_strerror. Update documentation/flags regarding new default hostname semantics --- Key: MESOS-1506 URL: https://issues.apache.org/jira/browse/MESOS-1506 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 0.18.0, 0.19.0, 0.20.0 Reporter: Vinod Kone https://issues.apache.org/jira/browse/MESOS-672 was committed in 0.18.0 which fixed redirection of WebUI. Included in this fix is https://reviews.apache.org/r/17573/ which changed how the SlaveInfo.hostname is calculated when --hostname is not provided. Specifically, slave now deduces the hostname from --ip flag when --hostname is not provided. We should update the slave/master flags and documentation (http://mesos.apache.org/documentation/latest/configuration/) reflecting this change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1506) Update documentation/flags regarding new default hostname semantics
[ https://issues.apache.org/jira/browse/MESOS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14152388#comment-14152388 ] Evelina Dumitrescu edited comment on MESOS-1506 at 9/30/14 2:19 AM: I think that there might be an inconsistency in getHostname. The comments(If the hostname cannot be resolved, then a string version of the IP address is returned) are not compliant with the behavior of the method. was (Author: evelinad): I think that there might be an inconsistency in getHostname. If the hostname cannot be resolved, then a string version of the IP address should be returned. Instead, if getnameinfo fails, an error string corresponding to the error code is returned by gai_strerror. Update documentation/flags regarding new default hostname semantics --- Key: MESOS-1506 URL: https://issues.apache.org/jira/browse/MESOS-1506 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 0.18.0, 0.19.0, 0.20.0 Reporter: Vinod Kone Assignee: Evelina Dumitrescu https://issues.apache.org/jira/browse/MESOS-672 was committed in 0.18.0 which fixed redirection of WebUI. Included in this fix is https://reviews.apache.org/r/17573/ which changed how the SlaveInfo.hostname is calculated when --hostname is not provided. Specifically, slave now deduces the hostname from --ip flag when --hostname is not provided. We should update the slave/master flags and documentation (http://mesos.apache.org/documentation/latest/configuration/) reflecting this change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
