Is it worth the energy to make these call-sites more resilient and fall-back on SERVICE_HOST if *_SERVICE_HOST does not exist?

LGTM, making this fallback probably makes sense, since we have lots of old directions/binaries for installing k8s.

--brendan

So long as we're continuing to use environment variables, why not just support the Docker links format (e.g., FOO_PORT_5432_TCP_ADDR=172.17.0.5)?

https://docs.docker.com/userguide/dockerlinks/

While you're updating the examples, it might be worth it to change REDISMASTER to be REDIS_MASTER. The first time I went through the example, I just copied everything. When I started to write my own pod configurations, I wanted my code to use a prettier environment variable with underscores and not just concatenating two words (e.g. REDISMASTER vs REDIS_MASTER). I wasn't 100% sure if the code would parse - from the pod label into _ for the environment variables. I just went out on a limb and guessed that it would, and it worked no problem. I'm sure most people are probably going to want to use environment variables that look like MY_ENV_VAR and not MYENVVAR. You could save some confusion or need to look into the code if you changed the example to illustrate that https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/registry/service/rest.go#L214 actually takes effect.

Added fallbacks to SERVICE_HOST

@razic - I'm going to decline that change for now - unrelated

@thockin I agree w/ @bgrant0607 the links support is already in there:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/registry/service/rest.go#L217

As long as we're changing the examples, let's change to use that syntax.

From what docs I can find, docker's vars are of the form (with commentary by me)

DB_NAME=/web2/db  ## not very useful to us

DB_PORT=tcp://172.17.0.5:5432  ## not useful without parsing

DB_PORT_5432_TCP=tcp://172.17.0.5:5432  ## not useful without parsing

DB_PORT_5432_TCP_PROTO=tcp  ## pre-supposes that I know the port number

DB_PORT_5432_TCP_PORT=5432  ## somewhat circular, given that I have to know the port

DB_PORT_5432_TCP_ADDR=172.17.0.5  ## almost useful, but it includes the port number

Those variables? Or are there some that are actually useful. What we want to present is "what host is service 'foo' on?" and "what port is service 'foo' on?" None of these vars answer either of those questions.

What am I missing?

I think that DB_PORT_5432_TCP_PORT is equivalent to DB_PORT and
DB_PORT_5432_TCP_ADDR is equivalent to your new per-service address.

On Tue, Sep 23, 2014 at 9:25 PM, Tim Hockin notifications@github.com
wrote:

From what docs I can find, docker's vars are of the form (with commentary
by me)

DB_NAME=/web2/db ## not very useful to us

DB_PORT=tcp://172.17.0.5:5432 ## not useful without parsing

DB_PORT_5432_TCP=tcp://172.17.0.5:5432 ## not useful without parsing

DB_PORT_5432_TCP_PROTO=tcp ## pre-supposes that I know the port number

DB_PORT_5432_TCP_PORT=5432 ## somewhat circular, given that I have to know the port

DB_PORT_5432_TCP_ADDR=172.17.0.5 ## almost useful, but it includes the port number

Those variables? Or are there some that are actually useful. What we want
to present is "what host is service 'foo' on?" and "what port is service
'foo' on?" None of these vars answer either of those questions.

What am I missing?

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

I don't get it. If I KNOW that the port is 5432, which must be the case in order for me to look up a variable with that number embedded in the name, why would I look up the value I already know?

I'm fine adding these variables but I really think they are pointless.

if you're exporting an explicit port (like 5432:5432) the variable is pointless. But say that you let docker assign a random port (:5432) then the DB_PORT_5432_TCP_PORT will give you that port.

Since each container has its own IP, there is no need for docker style port
mangling.

I think the variables are exclusively for discovery. If you know what you
are looking for, you need neither name (DNS) or port (known port), but if
you want to be able to easily introspect available services, environment
variables are convenient, without requiring users to link a k8s api layer.

Brendan
On Sep 24, 2014 12:03 AM, "Joakim Gustin" notifications@github.com wrote:

if you're exporting an explicit port (like 5432:5432) the variable is
pointless. But say that you let docker assign a random port (:5432) then
the DB_PORT_5432_TCP_PORT will give you that port.

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

Caveat, maybe there is something that I am TOTALLY MISSING on why these are useful.  If so, I'm happy to be wrong.

@gust1n Actually not.   At least not in my tests.

root@thockin-glaptop:/home/thockin# docker run --name foobar -d -p 123 -p 456 -p 789:666 ubuntu sleep 600
6d39183f2f3fc9e18902873926608b214ae134c87a251096d2017ed00bbcdc8d

root@thockin-glaptop:/home/thockin# docker run -ti --link foobar:aliasfoobar ubuntu bash
root@3f95d42ad513:/# set | grep -i FOOBAR
ALIASFOOBAR_NAME=/berserk_pasteur/aliasfoobar
ALIASFOOBAR_PORT=tcp://172.17.0.10:123
ALIASFOOBAR_PORT_123_TCP=tcp://172.17.0.10:123
ALIASFOOBAR_PORT_123_TCP_ADDR=172.17.0.10
ALIASFOOBAR_PORT_123_TCP_PORT=123
ALIASFOOBAR_PORT_123_TCP_PROTO=tcp
ALIASFOOBAR_PORT_456_TCP=tcp://172.17.0.10:456
ALIASFOOBAR_PORT_456_TCP_ADDR=172.17.0.10
ALIASFOOBAR_PORT_456_TCP_PORT=456
ALIASFOOBAR_PORT_456_TCP_PROTO=tcp
ALIASFOOBAR_PORT_666_TCP=tcp://172.17.0.10:666
ALIASFOOBAR_PORT_666_TCP_ADDR=172.17.0.10
ALIASFOOBAR_PORT_666_TCP_PORT=666
ALIASFOOBAR_PORT_666_TCP_PROTO=tcp

In order to use any of those variables, I have to already know the port number.  That's fine, but I really don't see ANY point in saying $ALIASFOOBAR_PORT_123_TCP_PORT when I know it will ALWAYS evaluate to 123.  Likewise $ALIASFOOBAR_PORT_123_TCP_PROTO = tcp.

I guess it's OK if you know the service name and port to get the IP, but is that really better than what we're offering with ALIASFOOBAR_SERVICE_HOST?

In short, I can not fathom why these vars are named the way they are. They seem less useful than they could be, to the point of near uselessness.

@brendanburns We still have env vars, they are still useful for introspection (I call it "shopping"). But the ones we have are actually useful, rather than a waste of memory.

FWIW, we already have all of the docker-compatible env vars populated, though there are bugs (I'll tackle some of those after this goes in).

I'm going to take the previous LGTM and self-commit, because I have a followup PR and I want to keep moving. We can argue about how to spell the env vars later.

Trying to run e2e first, not having much luck

e2e passed.