Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP #9

drnic · 2014-12-30T16:08:58Z

I think technically the $LATTICE_COORDINATOR_IP variable is really to allow diego cells' consul client to connect with the consul server; which might (currently is) running on the coordinator VM/job. Perhaps consider renaming it to CONSUL_SERVER_IP in preparation for allowing reuse of an existing consul server cluster and/or deployment of consul server outside of the coordinator job VM.

I think technically the $LATTICE_COORDINATOR_IP variable is really to allow diego cells' consul client to connect with the consul server; which might (currently is) running on the coordinator VM/job. Perhaps consider renaming it to CONSUL_SERVER_IP in preparation for allowing reuse of an existing consul server cluster and/or deployment of consul server outside of the coordinator job VM.

goehmen · 2014-12-30T18:20:05Z

I created https://www.pivotaltracker.com/story/show/85279452

onsi · 2014-12-30T21:42:03Z

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There are a number of things apart from consul on the coordinator box (e.g. etcd) and we don't use consul to discover all those things.

drnic · 2014-12-30T21:47:49Z

It was the only use case in the PR. Ultimately you would use consul for all other configuration though if there were additional reasons for client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri notifications@github.com
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There are a number of things apart from consul on the coordinator box (e.g. etcd) and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:
#9 (comment)

onsi · 2014-12-30T21:49:30Z

Diego itself doens't use consul to discover things like etcd, etc... and
relies on bosh static IPs instead so there's a bit of an impedance mismatch.

On Tue, Dec 30, 2014 at 1:47 PM, Dr Nic Williams notifications@github.com
wrote:

It was the only use case in the PR. Ultimately you would use consul for
all other configuration though if there were additional reasons for
client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri notifications@github.com
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There
are a number of things apart from consul on the coordinator box (e.g. etcd)

and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

drnic · 2014-12-30T21:51:23Z

ETA to stop using static IPs and support consul DNS hostnames?

On Tue, Dec 30, 2014 at 1:49 PM, Onsi Fakhouri notifications@github.com
wrote:

Diego itself doens't use consul to discover things like etcd, etc... and
relies on bosh static IPs instead so there's a bit of an impedance mismatch.
On Tue, Dec 30, 2014 at 1:47 PM, Dr Nic Williams notifications@github.com
wrote:

It was the only use case in the PR. Ultimately you would use consul for
all other configuration though if there were additional reasons for
client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri notifications@github.com
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There
are a number of things apart from consul on the coordinator box (e.g. etcd)

and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Reply to this email directly or view it on GitHub:
#9 (comment)

drnic · 2014-12-30T21:53:26Z

Where in lattice is Diego-cell using LAT_COORD_IP than for consul client? (Sorry can't spot it)

On Tue, Dec 30, 2014 at 1:49 PM, Onsi Fakhouri notifications@github.com
wrote:

Diego itself doens't use consul to discover things like etcd, etc... and
relies on bosh static IPs instead so there's a bit of an impedance mismatch.
On Tue, Dec 30, 2014 at 1:47 PM, Dr Nic Williams notifications@github.com
wrote:

It was the only use case in the PR. Ultimately you would use consul for
all other configuration though if there were additional reasons for
client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri notifications@github.com
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There
are a number of things apart from consul on the coordinator box (e.g. etcd)

and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Reply to this email directly or view it on GitHub:
#9 (comment)

diego-edge-ci · 2014-12-30T21:55:10Z

re "ETA to stop using static IPs and support consul DNS hostnames? " -- not
a very high priority at this point.
re LAT_COORD_IP -- I'm not sure -- someone closer to the lattice code will
ned to respond.

On Tue, Dec 30, 2014 at 1:53 PM, Dr Nic Williams notifications@github.com
wrote:

Where in lattice is Diego-cell using LAT_COORD_IP than for consul client?
(Sorry can't spot it)

On Tue, Dec 30, 2014 at 1:49 PM, Onsi Fakhouri notifications@github.com
wrote:

Diego itself doens't use consul to discover things like etcd, etc... and
relies on bosh static IPs instead so there's a bit of an impedance
mismatch.
On Tue, Dec 30, 2014 at 1:47 PM, Dr Nic Williams <
notifications@github.com>
wrote:

It was the only use case in the PR. Ultimately you would use consul for
all other configuration though if there were additional reasons for
client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri <
notifications@github.com>
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul.
There
are a number of things apart from consul on the coordinator box (e.g.
etcd)

and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
<
https://github.com/pivotal-cf-experimental/lattice/pull/9#issuecomment-68402187>

.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

drnic · 2014-12-30T21:55:57Z

This PR is just for lattice if it helps

On Tue, Dec 30, 2014 at 1:55 PM, diego-edge-ci notifications@github.com
wrote:

re "ETA to stop using static IPs and support consul DNS hostnames? " -- not
a very high priority at this point.
re LAT_COORD_IP -- I'm not sure -- someone closer to the lattice code will
ned to respond.
On Tue, Dec 30, 2014 at 1:53 PM, Dr Nic Williams notifications@github.com
wrote:

Where in lattice is Diego-cell using LAT_COORD_IP than for consul client?
(Sorry can't spot it)

On Tue, Dec 30, 2014 at 1:49 PM, Onsi Fakhouri notifications@github.com
wrote:

Diego itself doens't use consul to discover things like etcd, etc... and
relies on bosh static IPs instead so there's a bit of an impedance
mismatch.
On Tue, Dec 30, 2014 at 1:47 PM, Dr Nic Williams <
notifications@github.com>
wrote:

It was the only use case in the PR. Ultimately you would use consul for
all other configuration though if there were additional reasons for
client-server connections?

On Tue, Dec 30, 2014 at 1:42 PM, Onsi Fakhouri <
notifications@github.com>
wrote:

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul.
There
are a number of things apart from consul on the coordinator box (e.g.
etcd)

and we don't use consul to discover all those things.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
<
https://github.com/pivotal-cf-experimental/lattice/pull/9#issuecomment-68402187>

.

Reply to this email directly or view it on GitHub:

#9 (comment)

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Reply to this email directly or view it on GitHub:
#9 (comment)

davidwadden · 2014-12-31T20:24:42Z

at the moment, you're right - the only use of the LATTICE_COORDINATOR_IP variable is for the Consul endpoint. let me review the services a little more and see this this makes sense or not.

a compromise solution could be to have both variables, the CONSUL_SERVER_IP for the Consul configuration and a LATTICE_COORDINATOR_IP for (everything else) -- assuming its needed. then it would support that decoupled configuration to have the consul server not hosted on the coordinator vm.

drnic · 2014-12-31T21:02:24Z

I think the future goal for all our cluster configurations would be to discover configuration from consul; so it's the sole static IP bootstrapping requirement. Here's to 2015 New Years resolutions! :)

On Wed, Dec 31, 2014 at 12:24 PM, davidwadden notifications@github.com
wrote:

at the moment, you're right - the only use of the LATTICE_COORDINATOR_IP variable is for the Consul endpoint. let me review the services a little more and see this this makes sense or not.

a compromise solution could be to have both variables, the CONSUL_SERVER_IP for the Consul configuration and a LATTICE_COORDINATOR_IP for (everything else) -- assuming its needed. then it would support that decoupled configuration to have the consul server not hosted on the coordinator vm.

Reply to this email directly or view it on GitHub:
#9 (comment)

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP [Finishes #85279452]

+ Bump Version Files Diego Release: 0.1365.0 Diego Release Git SHA: 2be0682c4eeff45057c8e687cfca1a920a07b24d [Delivers #99785964] [Delivers #98882812] [Delivers #98882812] [Delivers #99708666] [Delivers #99457744] +Committed by GOCD- Run #9 of Pipeline: lattice, Stage: promote_and_publish, JOB: promote_and_publish

+ Update terraform example files to point to source v0.2.7-32-g9eaf1a7 + Terraform now downloads Lattice v0.2.7-31-g868be59 +Committed by GOCD- Run #9 of Pipeline: lattice, Stage: promote_and_publish, JOB: promote_and_publish

davidwadden added a commit that referenced this pull request Jan 5, 2015

Merge pull request #9 from drnic/consul-server-ip-var

7e8abef

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP [Finishes #85279452]

davidwadden merged commit 7e8abef into cloudfoundry-attic:develop Jan 5, 2015

davidwadden self-assigned this Jan 5, 2015

drnic unassigned davidwadden Feb 19, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP #9

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP #9

drnic commented Dec 30, 2014

goehmen commented Dec 30, 2014

onsi commented Dec 30, 2014

drnic commented Dec 30, 2014

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There are a number of things apart from consul on the coordinator box (e.g. etcd) and we don't use consul to discover all those things.

onsi commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

diego-edge-ci commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

davidwadden commented Dec 31, 2014

drnic commented Dec 31, 2014

a compromise solution could be to have both variables, the CONSUL_SERVER_IP for the Consul configuration and a LATTICE_COORDINATOR_IP for (everything else) -- assuming its needed. then it would support that decoupled configuration to have the consul server not hosted on the coordinator vm.

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP #9

Rename $LATTICE_COORDINATOR_IP to $CONSUL_SERVER_IP #9

Conversation

drnic commented Dec 30, 2014

goehmen commented Dec 30, 2014

onsi commented Dec 30, 2014

drnic commented Dec 30, 2014

I'm not sure that LATTICE_COORDINATOR_IP is only used for consul. There are a number of things apart from consul on the coordinator box (e.g. etcd) and we don't use consul to discover all those things.

onsi commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

diego-edge-ci commented Dec 30, 2014

and we don't use consul to discover all those things.

drnic commented Dec 30, 2014

and we don't use consul to discover all those things.

davidwadden commented Dec 31, 2014

drnic commented Dec 31, 2014

a compromise solution could be to have both variables, the CONSUL_SERVER_IP for the Consul configuration and a LATTICE_COORDINATOR_IP for (everything else) -- assuming its needed. then it would support that decoupled configuration to have the consul server not hosted on the coordinator vm.