Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

[proxy] More flexible container name -> hostname derivation #1126

Merged
merged 3 commits into from
Jul 14, 2015

Conversation

2opremio
Copy link
Contributor

Provides a new "--hostname=substitution" flag to WeaveProxy, where
'substitution' is a sed-style substitution command. 'substitution' will be
applied to container names at launch-time, as a means to control what hostnames will
be registered in WeaveDNS.

The substitution is implemented with
https://golang.org/pkg/regexp/#Regexp.ReplaceAllString . Thus, references to
regexp substitution groups should be prepended with a dollar sign.

For instance, if we provide "--hostname='/aws-[0-9]+-(.*)/my-app-$1/'", running
a container named 'aws-12798186823-foo' through WeaveProxy will lead to WeaveDNS
registering 'my-app-foo'.

Closes #1018

@tomwilkie
Copy link
Contributor

we'll need a few lines in the docs too, please.

@2opremio
Copy link
Contributor Author

@tomwilkie Sure, I considered it but it wasn't clear to me where to include the documentation. https://github.com/weaveworks/weave/tree/master/docs only seems to include architectural stuff.

@2opremio
Copy link
Contributor Author

OK, I found /site which I hadn't payed attention to until now. I will add something there first thing tomorrow.

@2opremio
Copy link
Contributor Author

@tomwilkie Done, I will squash the commit once the PR is good to go.

@2opremio 2opremio force-pushed the issues/1018-more-flexible-hostname-derivation branch 2 times, most recently from 95e7663 to 32a24b0 Compare July 14, 2015 11:01
@2opremio
Copy link
Contributor Author

Rebased with master (and squashed the documentation commit) to make coveralls happy

@tomwilkie
Copy link
Contributor

You should fetch the coverage.txt from your branch and diff it with master to see where this -5% is coming from.

@@ -36,7 +36,7 @@ weave launch-router [--password <password>] [--nickname <nickname>]
[--no-discovery] [--init-peer-count <count>] <peer> ...
weave launch-dns [<addr>]
weave launch-proxy [-H <endpoint>] [--with-dns | --without-dns]
[--no-default-ipalloc] [--no-rewrite-hosts]
[--no-default-ipalloc] [--no-rewrite-hosts] [--hostname]

This comment was marked as abuse.

@2opremio
Copy link
Contributor Author

@tomwilkie Thanks, will do. I suspect it's coming from proxy/ not having any tests until now.

execCreateRegexp = regexp.MustCompile("^(/v[0-9\\.]*)?/containers/[^/]*/exec$")
containerCreateRegexp = regexp.MustCompile(`^(/v[0-9\.]*)?/containers/create$`)
containerStartRegexp = regexp.MustCompile(`^(/v[0-9\.]*)?/containers/[^/]*/(re)?start$`)
execCreateRegexp = regexp.MustCompile(`^(/v[0-9\.]*)?/containers/[^/]*/exec$`)

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

@tomwilkie
Copy link
Contributor

Alternatively, instead of requireing a sed-style regex in the for /foo/bar/, how about we just have --hostname-match=foo and --hostname-replacement=bar? It would save us a bunch of code (using regexes to parse regexes...) Default for --hostname-match should be (.*) and --hostname-replacement should be $1

Also, I wouldn't bother including this in the weave usage text; this feature is meant for integrators only. Just include it in the site/ docs.

@2opremio
Copy link
Contributor Author

@tomwilkie I personally like the /regexp/replacement/ syntax better, @rade also seems to agree as per #1018

Also, I am not sure it makes sense not to document it in the usage if it's in the docs. If we want it to be hidden from normal users then it shouldn't appear on the site.

@tomwilkie
Copy link
Contributor

@rade what do you think? I suggested this as I'm not sure the parsing of the sed-style regexps is worth the extra code.

@2opremio 2opremio force-pushed the issues/1018-more-flexible-hostname-derivation branch from 32a24b0 to 1c543a2 Compare July 14, 2015 13:42
@2opremio
Copy link
Contributor Author

I pushed a commit which should address all the code comments (except for @tomwilkie's design remark). Also, I pushed a change to surround relevant regexps with ^ and $.

Please make sure to squash the changes before merging.


check() {
assert "proxy exec_on $HOST1 $1 getent hosts $2 | tr -s ' '" "$3 $2"
}

This comment was marked as abuse.

This comment was marked as abuse.

@rade
Copy link
Member

rade commented Jul 14, 2015

I'm not sure the parsing of the sed-style regexps is worth the extra code.

Agreed, and I am not sold on the UI benefits either.

So two options it is, with the defaults as you suggest. But I do think they should be documented in the usage.

@2opremio
Copy link
Contributor Author

OK, I will rework the PR to use those two options.

Provides to new two new flags: `--hostname-match <regexp>`
and `--hostname-replacement <replacement>`. When launching a container, its name
matched against regular expression `<regexp>`. Then, based on that match,
`<replacement>` will be used to generate a hostname, which will ultimately be
handed over to weaveDNS for registration.

The substitution is implemented with
https://golang.org/pkg/regexp/#Regexp.ReplaceAllString . Thus, references to
regexp substitution groups should be prepended with a dollar sign.

For instance, if we provide `--hostname-match '^aws-[0-9]+-(.*)$'` and
`--hostname-replacement 'my-app-$1'`, running a container named
`aws-12798186823-foo` through WeaveProxy will lead to WeaveDNS registering
`my-app-foo`.

Closes #1018
@2opremio 2opremio force-pushed the issues/1018-more-flexible-hostname-derivation branch from 1c543a2 to 4f82dc9 Compare July 14, 2015 14:43
@2opremio
Copy link
Contributor Author

@rade @paulbellamy @tomwilkie please review

dockerSock = "/var/run/docker.sock"
dockerSockUnix = "unix://" + dockerSock
substitutionPatternName = "pattern"
substitutionReplacementName = "replacement"

This comment was marked as abuse.

@2opremio
Copy link
Contributor Author

@tomwilkie It seems there are GCP quota problems in circleci https://circleci.com/gh/weaveworks/weave/1835

@tomwilkie
Copy link
Contributor

Yes I've just cleared out some stale VMs. VMs aren't cleaned up if you
click cancel.

On Tue, Jul 14, 2015 at 4:15 PM, Alfonso Acosta [email protected]
wrote:

@tomwilkie https://github.com/tomwilkie It seems there are GCP quota
problems in circleci https://circleci.com/gh/weaveworks/weave/1835


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

@2opremio 2opremio force-pushed the issues/1018-more-flexible-hostname-derivation branch from 0777fce to ded3d6b Compare July 14, 2015 15:31
@@ -37,6 +37,7 @@ weave launch-router [--password <password>] [--nickname <nickname>]
weave launch-dns [<addr>]
weave launch-proxy [-H <endpoint>] [--with-dns | --without-dns]
[--no-default-ipalloc] [--no-rewrite-hosts]
[--hostname-match <regexp>] [--hostname-replacement <replacement>]

This comment was marked as abuse.

rade added a commit that referenced this pull request Jul 14, 2015
…ivation

[proxy] More flexible container name -> hostname derivation

Closes #1018.
@rade rade merged commit 7ae06ef into master Jul 14, 2015
@rade rade deleted the issues/1018-more-flexible-hostname-derivation branch July 14, 2015 16:32
rade added a commit that referenced this pull request Jul 14, 2015
This wasn't spotted because #1065, which removed launch-dns, got
merged just before #1126, which introduced this test.
rade added a commit that referenced this pull request Jul 14, 2015
These tests were introduced in #1065 and #1126.
@2opremio
Copy link
Contributor Author

@rade Thanks. Out of curiosity, is there a reason why fix-commits are not squashed before merging? (Commits like ded3d6b don't make any sense out of context) I added extra commits to make clear what was being changed, with the intention of squashing them before merging. Should I had kept amending instead?

@rade
Copy link
Member

rade commented Jul 14, 2015

I didn't realise you wanted to squash some commits. Better leave a note in the PR next time.

@2opremio
Copy link
Contributor Author

@rade Sorry, I was expecting the merger to check the commits before going ahead. This is probably not the forum for this discussion but, in order to avoid these situations, wouldn't it make sense to let the author merge the code himself after getting a "go ahead"?

@rade
Copy link
Member

rade commented Jul 14, 2015

I was expecting the merger to check the commits before going ahead.

I did. I'm not bothered by the non-squashed commits; There is enough context to trace them back to this PR.

This is probably not the forum for this discussion

Correct.

@2opremio
Copy link
Contributor Author

@rade ok, fair enough :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants