[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-4255: -- Story Points: 5 (was: 3) > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > Fix For: 0.28.0 > > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-4255: - Sprint: Mesosphere Sprint 28 > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-4255: -- Sprint: (was: Mesosphere Sprint 26) > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Arya updated MESOS-4255: -- Target Version/s: 0.28.0 (was: 0.27.0) > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-4255: -- Shepherd: Vinod Kone Sprint: Mesosphere Sprint 26 > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar >Assignee: Anand Mazumdar > Labels: mesosphere > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4255) Add mechanism for testing recovery of HTTP based executors
[ https://issues.apache.org/jira/browse/MESOS-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-4255: -- Description: Currently, the slave process generates a process ID every time it is initialized via {{process::ID::generate}} function call. This is a problem for testing HTTP executors as it can't retry if there is a disconnection after an agent restart since the prefix is incremented. {code} Agent PID before: slave(1)@127.0.0.1:43915 Agent PID after restart: slave(2)@127.0.0.1:43915 {code} There are a couple of ways to fix this: - Add a constructor to {{Slave}} exclusively for testing that passes on a fixed {{ID}} instead of relying on {{ID::generate}}. - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to (1), we can default to the last known active ID. was: Currently, the slave process generates a process ID every time it is initialized via {{process::ID::generate}} function call. This is a problem for testing HTTP executors as it can't retry if there is a disconnection after an agent restart since the prefix is incremented. {code} Agent PID before: slave(1)@127.0.0.1:43915 Agent PID after restart: slave(2)@127.0.0.1:43915 There are a couple of ways to fix this: - Add a constructor to {{Slave}} exclusively for testing that passes on a fixed {{ID}} instead of relying on {{ID::generate}}. - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to (1), we can default to the last known active ID. > Add mechanism for testing recovery of HTTP based executors > -- > > Key: MESOS-4255 > URL: https://issues.apache.org/jira/browse/MESOS-4255 > Project: Mesos > Issue Type: Bug >Reporter: Anand Mazumdar > Labels: mesosphere > > Currently, the slave process generates a process ID every time it is > initialized via {{process::ID::generate}} function call. This is a problem > for testing HTTP executors as it can't retry if there is a disconnection > after an agent restart since the prefix is incremented. > {code} > Agent PID before: > slave(1)@127.0.0.1:43915 > Agent PID after restart: > slave(2)@127.0.0.1:43915 > {code} > There are a couple of ways to fix this: > - Add a constructor to {{Slave}} exclusively for testing that passes on a > fixed {{ID}} instead of relying on {{ID::generate}}. > - Currently we delegate to slave(1)@ i.e. (1) when nothing is specified as > the URL in libprocess i.e. {{127.0.0.1:43915/api/v1/executor}} would delegate > to {{slave(1)@127.0.0.1:43915/api/v1/executor}}. Instead of defaulting to > (1), we can default to the last known active ID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)