Add router support for wildcard domains (*.foo.com) #11201

ramr · 2016-10-04T01:38:32Z

For trello card: https://trello.com/c/cX42kXSA/222-7-subdomain-wildcard-router-ingress-demo

Still need to beef up the tests + address route ownership/replacement (for wildcard to overlapping routes) but this has support for the card via an environment variable + allows a {white,black}listing of host names. The route ownership/replacement might make this PR a bit too big - its big enough as is.

@knobunc @rajatchopra @marun @smarterclayton if you have some preliminary feedback that would be greatly appreciated. Thx

ramr · 2016-10-04T01:38:40Z

[test]

smarterclayton · 2016-10-04T01:41:03Z

I assume now route admission has to check for prefix overlaps on route
names in the same namespace? How will this work when we move to Ingress?

On Oct 3, 2016, at 9:38 PM, Ram Ranganathan notifications@github.com
wrote:

For trello card:
https://trello.com/c/cX42kXSA/222-7-subdomain-wildcard-router-ingress-demo

Still need to beef up the tests + address route ownership/replacement (for
wildcard to overlapping routes) but this has support for the card via an
environment variable + allows a {white,black}listing of host names. The
route ownership/replacement might make this PR a bit too big - its big
enough as is.

@knobunc https://github.com/knobunc @rajatchopra
https://github.com/rajatchopra @marun https://github.com/marun
@smarterclayton https://github.com/smarterclayton if you have some

preliminary feedback that would be greatly appreciated. Thx

You can view, comment on, or merge this pull request online at:

#11201
Commit Summary

Convert from cert directory to using a map for certificates and
present the
o Allow wildcard (currently only *.) routes to be created and add
tests.

File Changes

M images/router/haproxy/Dockerfile
https://github.com/openshift/origin/pull/11201/files#diff-0 (2)
M images/router/haproxy/conf/haproxy-config.template
https://github.com/openshift/origin/pull/11201/files#diff-1 (134)
M pkg/cmd/infra/router/f5.go
https://github.com/openshift/origin/pull/11201/files#diff-2 (22)
M pkg/cmd/infra/router/router.go
https://github.com/openshift/origin/pull/11201/files#diff-3 (78)
M pkg/cmd/infra/router/template.go
https://github.com/openshift/origin/pull/11201/files#diff-4 (3)
M pkg/route/api/validation/validation.go
https://github.com/openshift/origin/pull/11201/files#diff-5 (20)
M pkg/route/api/validation/validation_test.go
https://github.com/openshift/origin/pull/11201/files#diff-6 (121)
A pkg/router/controller/host_admitter.go
https://github.com/openshift/origin/pull/11201/files#diff-7 (65)
A pkg/router/controller/host_admitter_test.go
https://github.com/openshift/origin/pull/11201/files#diff-8 (219)
M pkg/router/template/plugin.go
https://github.com/openshift/origin/pull/11201/files#diff-9 (2)
M pkg/router/template/router.go
https://github.com/openshift/origin/pull/11201/files#diff-10 (16)
M pkg/router/template/types.go
https://github.com/openshift/origin/pull/11201/files#diff-11 (3)

Patch Links:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11201, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p6pdAPp_C_BRTKW3qtXoblcWA1hiks5qwa4agaJpZM4KNODA
.

liggitt · 2016-10-04T01:46:37Z

Can we separate out the cert map bit? There's a chance we'll want to backport that (along with enabling cert validation in the API by default)

ramr · 2016-10-04T05:25:01Z

@smarterclayton yes route admission now has to check for ownership of a subdomain and handle overlaps between wildcard and non-wildcard host names. As re: working with ingress - it would be work similarly as ingress specifies the wildcards within the rules/host (had originally intended to do this using annotations but that would have caused us to diverge from ingress).

@liggitt yeah, I can break out the cert validation bits tomorrow (along with a separate simpler/just enable extended validation PR so that its easier to backport).

bmeng · 2016-10-09T09:55:16Z

images/router/haproxy/conf/haproxy-config.template

@@ -100,15 +100,36 @@ frontend public
  acl secure_redirect base,map_beg(/var/lib/haproxy/conf/os_edge_http_redirect.map) -m found
  redirect scheme https if secure_redirect

+{{ if matchPattern "true|TRUE" (env "ROUTER_ALLOW_WILDCARD_ROUTES" "")}}


Will also meet this condition when the value is 1?

We could do a 1 in that set as well if need be but true|TRUE follows the other parameters in this file.

Yeah, let's just support true for now. The SYN eater I added got it backwards and added '1' so I fixed that later and support 'true' and '1', but 'true' is preferred.

liggitt · 2016-10-10T16:07:54Z

pkg/cmd/infra/router/router.go

+
+func hostInDomainList(host string, domains []string) bool {
+	for _, dom := range domains {
+		if strings.HasSuffix(host, fmt.Sprintf(".%s", dom)) {


this seems like a really expensive way to check this

do you recommend using sort.Search? For a small set in the list, it might not be as performant though.

this is called for every host. we shouldn't be sprintfing inside a loop, the allocations will kill us.

instead, I'd expect a sets.String object containing the domains, and to iterate over the host, finding locations of . and checking shorter and shorter substrings against the domain set.

func hostInDomainList(host string, domains sets.String) bool { if domains.Has(host) { return true } if i := strings.IndexRune(host, '.'); i >= 0 { return hostInDomainList(host[i+1:], domains) } return false }

liggitt · 2016-10-10T16:08:59Z

pkg/cmd/infra/router/router.go

@@ -43,6 +44,14 @@ type RouterSelection struct {
 	ProjectLabels        labels.Selector

 	IncludeUDP bool
+
+	DeniedDomains      string
+	BlacklistedDomains []string


you just need the []string var, bind it to a StringSliceVar flag

will change to that - thx

liggitt · 2016-10-10T16:12:38Z

pkg/router/template/plugin.go

@@ -107,6 +107,8 @@ func NewTemplatePlugin(cfg TemplatePluginConfig, lookupSvc ServiceLookup) (*Temp
 		"matchPattern":      matchPattern,      //anchors provided regular expression and evaluates against given string
 		"isInteger":         isInteger,         //determines if a given variable is an integer
 		"matchValues":       matchValues,       //compares a given string to a list of allowed strings
+
+		"genDomainWildcardRegexp": genDomainWildcardRegexp, //generates a regular expression matching wildcard hosts (and paths) for a [sub]domain


do we have tests in place to make sure we don't break the "API" we're surfacing for custom template files to use?

Still adding tests - would be with the unique_host checks.

We should add the tests against the template struct as it exists prior to this PR

liggitt · 2016-10-10T16:13:21Z

pkg/router/template/router.go

+func genDomainWildcardRegexp(hostname, path string, exactPath bool) string {
+	route := &routeapi.Route{Spec: routeapi.RouteSpec{Host: hostname}}
+	host, _ := validation.NormalizeWildcardRoute(route)
+	expr := regexp.QuoteMeta(fmt.Sprintf(".%s%s", host, path))


does go regex quoting exactly match haproxy config file regex quoting?

The quoting should but its RE2 vs PCRE. That said though, the only meta character we are using here is * and . - which is ok.

ramr · 2016-10-14T06:28:41Z

[test]

ramr · 2016-10-14T06:32:29Z

this is now ready for review. will add a couple more tests tomorrow. PTAL thx

Spent a while debugging this today - there was a big issue this found with:
14ec738
which would return true even if a route had an older timestamp which the host_admitter_test was expecting.

And this is also waiting on #11217 to merge - one of the commits (for the cert list) would then drop off this PR.

Updated commit sha

marun

Nothing functional to note. My main suggestion would be simpler testing to make it easier to evaluate test quality.

marun · 2016-10-14T15:55:13Z

pkg/route/api/helper.go

+		if route1.UID < route2.UID {
+			return true
+		}
+		if route1.Namespace < route2.Namespace {


Sorry about that, this bug was my fault.

As you say, comparisons with other fields only make sense if the timestamps are equal. Given that UIDs can never be equal, though, what would be the point of comparing other fields? Consider removing namespace and name comparison:

if route1.CreationTimestamp == route2.CreationTimestamp { if route1.UID < route2.UID { return true } } return false

Will do - have to check implications to the other tests (plugin_tests). Should be ok I think - just need to ensure that UIDs are not the same in any of tests.

I'll keep this for now as a few other tests use it.

Was this only in 1.4 or also in 1.3? IF so we need to backport.

The change was done in April - so should be 1.3 as well.
ee4035a
@marun can confirm.

And did you mean backport on 1.3 on origin or OSE or both?

marun · 2016-10-14T16:06:06Z

pkg/route/api/validation/validation.go

+
+// NormalizeWildcardRoute tests if a route host is wildcarded and returns
+// the "normalized" (domain name currently) form of the route host.
+func NormalizeWildcardRoute(route *routeapi.Route) (string, bool) {


Consider simplifying this function according to the Law of Demeter:

func NormalizeWildcardRoute(host string) (string, bool) {...}

This would simplify testing since a route object would no longer be required.

I guess if we do that - might be better to pull the function into helper.go.

marun · 2016-10-14T16:32:03Z

pkg/router/controller/host_admitter.go

+	return nil
+}
+
+func getRouteSubdomain(route *routeapi.Route) string {


Consider passing the host instead of the route (Demeter).

marun · 2016-10-14T17:02:07Z

pkg/router/controller/host_admitter_test.go

@@ -0,0 +1,399 @@
+package controller


Consider simplifying these tests by validating each function exhaustively in isolation but minimally in combination. This would allow fewer test cases to provide more coverage. At the least I suggest testing addRoute and HandleRoute separately.

marun · 2016-10-14T17:06:38Z

pkg/router/controller/host_admitter_test.go

+		errors bool
+	}{
+		{
+			name: "No Host",


Consider simplifying by creating route objects in the test rather than the test data, e.g.

tests := []struct { name string routeName string host string errors bool }

The created routes are different though as they test for variations in the name/namespace and CreationTimestamp and the Spec.Host.

This particular function doesn't vary the namespace but even if it did it would be simpler to include namespace as a variable:

tests := []struct { name string routeName string namespace string host string errors bool }{ { name: "Blocked Host", routeName: "blocked", namespace: "host", host: "host.domain.blocked.test", errors: true, }, } for _, tc := range tests { route := &routeapi.Route{ ObjectMeta: kapi.ObjectMeta{ Name: tc.routeName Namespace: tc.namespace, }, Spec: routeapi.RouteSpec{ Host: tc.host, } } err := admitter.HandleRoute(watch.Added, route) }

The ordinal relationship of tests's CreationTimestamp would be the same, since the routes would still be created in the same order.

I want to explicitly add routes with different timestamps out of band to check - rather than do a sequential check.

never mind, I saw you meant the previous test TestHostAdmit.

marun · 2016-10-14T17:08:56Z

pkg/router/controller/host_admitter_test.go

+	r.rejections[r.rejectionKey(route)] = reason
+}
+
+func admissionChecker(denyDomain string, allowWildcards bool) RouteAdmissionFunc {


Given that the only point of the admitter function in this file's testing is to ensure that HandleRoute executes route rejection, consider using an anonymous function that statically returns nil or err.

The parameters to the admissionChecker function are different for the different tests and NewHostAdmitter takes that generated function as an input parameter.

I get that, but these are unit tests. The only thing the checker does is indicate to HandleRoute whether a route should be rejected or not, so there's no point in adding logic that enables more than that.

I don't have a strong opinion either way and will do it but to create 3/4 copies of this anonymized (or named) with a small variation seemed a bit too excessive.

ramr · 2016-10-15T03:18:08Z

[test]

ramr · 2016-10-17T19:15:08Z

[test]

knobunc · 2016-10-17T20:08:05Z

[test]

ramr · 2016-10-18T18:22:54Z

@smarterclayton / @liggitt could you PTAL thx

knobunc

LGTM. Thanks @ramr

knobunc · 2016-10-18T18:27:25Z

images/router/haproxy/conf/haproxy-config.template

@@ -100,15 +100,36 @@ frontend public
  acl secure_redirect base,map_beg(/var/lib/haproxy/conf/os_edge_http_redirect.map) -m found
  redirect scheme https if secure_redirect

+{{ if matchPattern "true|TRUE" (env "ROUTER_ALLOW_WILDCARD_ROUTES" "")}}


Yeah, let's just support true for now. The SYN eater I added got it backwards and added '1' so I fixed that later and support 'true' and '1', but 'true' is preferred.

knobunc · 2016-10-18T18:30:10Z

pkg/cmd/infra/router/router.go

+	}
+
+	if hostInDomainList(route.Spec.Host, o.BlacklistedDomains) {
+		glog.V(4).Infof("host %s in list of denied domains", route.Spec.Host)


Should we put quotes around the hostnames? Or is that not the pattern elsewhere?

I think most/majority of the logs don't have quotes. Probably more readable without it I think.

knobunc · 2016-10-18T18:39:08Z

pkg/router/template/router.go

+// for a [sub]domain.
+func genDomainWildcardRegexp(hostname, path string, exactPath bool) string {
+	route := &routeapi.Route{Spec: routeapi.RouteSpec{Host: hostname}}
+	host, _ := routeapi.NormalizeWildcardHost(route.Spec.Host)


It feels a little odd to generate wildcards even if the host doesn't have a leading wildcard. But I don't know how to handle the error path, and we are checking in the config file that they do... so it should be safe.

Its a helper function for the template. Yeah its called from the template which calls it for wildcard routes.

Wouldn't harm if we explicitly just checked the boolean value returned by NormalizeWildcardHost. Its a function exposed in the template, who knows how/where field use may call it with. If I just call it without a leading '*' for example, outside the scope of $cfg.IsWildcard check.

smarterclayton · 2016-10-20T18:32:29Z

pkg/route/api/helper.go

@@ -20,11 +20,16 @@ func RouteLessThan(route1, route2 *Route) bool {
 	if route1.CreationTimestamp.Before(route2.CreationTimestamp) {


Please change the commit description to be more descriptive of the change :) It massively helps me when I'm trying to draft release notes and need to read through 1000+ commits if the subject of each commit reflects the actual change.

rajatchopra · 2016-10-20T19:53:46Z

Fix that exposed genDomainWildcardRegexp function for cases where it is called without check on $cfg.IsWildcard.
Other than that it LGTM.

smarterclayton · 2016-10-24T19:46:16Z

This is the same criteria every API change for the last two years has gone through. We've made a few, very rare exceptions, and they have been almost completely for the following:

incompatibilities with Kube due to how our releases were handled (serviceAccountName, port validation)
bugs (was broken completely)
security issues (we tightened validation, for instance, or simply ignored input).

smarterclayton · 2016-10-24T19:55:15Z

Jordan's arguing for a net new field (on the side) - that would be:

host string // means I want this host
hostSpec string // means I want this hostSpec, and host must be empty

That's potentially valid and would be equivalent to the users and subjects fields in role bindings. The difference being:

We'd have to stop defaulting host on the API server, which means that we'd break compatibility for routers that don't fill that value
If host is set you must ignore hostSpec, which means old and new clients must pick one or the other to set.

We'd probably have to have a master flag to change the defaulting behavior, or likewise require a cluster admin to opt in.

smarterclayton · 2016-10-24T19:57:19Z

This is really no different than TLS termination policy (the other example of adding a policy that changed the default). Opt-in behavior that new routers understood (and behaved differently) and old routers ignored.

marun · 2016-10-24T19:59:18Z

What is hostSpec going to support that host and isWildcard or wildcardPolicy could not? It's not clear to me from your comments what @liggitt intends.

marun · 2016-10-24T20:00:28Z

I think it's worth considering just how much flexibility we want to build into routes with an impending move towards upstream ingress looming.

marun · 2016-10-24T20:08:22Z

pkg/router/controller/host_admitter.go

@@ -0,0 +1,204 @@
+package controller


Why is it desirable to add a new plugin vs updating UniqueHost to support wildcard routes? I don't understand why it wouldn't be simpler and less error prone to reuse the existing logic with normalized host values.

smarterclayton · 2016-10-24T20:25:15Z

Jordan to insert his clever suggestion that preserves compatibility (needs feedback on the original use case and the outcome) HERE:

ramr · 2016-10-24T20:25:49Z

@smarterclayton - what about using an annotation then (for isWildcard/wildcardPolicy/hostSpec)? That way there's no API changes needed.

The route says I want a host acme.test and wildcard support:

haproxy.router.openshift.io/wildcard == "SubdomainOnly" || "HostAndSubdomain"  || "None"

subdomain == nested in your previous comments.

Older routers would ignore that annotation (well it would give you a host acme.test - equivalent of "None" as older routers have no wildcard support). And the newer router would admit/deny it based on its policy - if the router runs with wildcard support, it would admit it in with wildcards, otherwise it could reject the wildcards (or allow the host part of it in acme.test).

Thoughts?

liggitt · 2016-10-24T20:28:37Z

we need to keep in mind how route.spec.host and route.status is used by all clients. that includes:

routers (used to serve routes)
web consoles (used for linking to routes)
oauth server (used to validate redirects to pods served via routes)

we can maintain compatibility with all of those clients if the host field continues to contain a prototypical dns name, and we make the wildcard request a separate field that indicates wildcarding of the first segment is requested:

host: www.foo.com
wildcardPolicy: Subdomain

would get you www.foo.com on old routers, and *.foo.com on routers supporting wildcards, with www.foo.com still reflected in route status in both cases (which gives a specific hostname to clients that need that for surfacing links, etc). (I'd expect a wildcardPolicy in the route.status as well to reflect whether that was enabled for the route... old routers would set it to false, the new router would set it based on the feature enablement)

smarterclayton · 2016-10-24T20:30:36Z

And if you didn't want the name to be valid, you could always choose "zzzzzzzz.foo.com" or something to indicate it's not real.

smarterclayton · 2016-10-24T20:35:27Z

I think i'd be ok with this for the primary concerns I had earlier.

eparis · 2016-10-24T20:43:10Z

@liggitt suggestion in #11201 (comment) is the least offensive thing I've heard.

I do wonder if 'wildcard' should be a string instead of a bool. For now the only valid string could be single (or something like that). But it leaves our options open....

smarterclayton · 2016-10-24T20:45:54Z

that would be wildcardPolicy. I'd prefer a constant string field over a boolean as well. None and Single or some other word that represents the last segment.

Ram, how much disruption to the current code is this?

ramr · 2016-10-24T20:55:18Z

@smarterclayton shouldn't be that much hopefully. Will need to adjust the flow upto the admission controller and remove some code (validation etc) - beyond the admission controllers, it would be the same - maybe a minor change to the existing function to get the subdomain part from the host for generating the regexp.
IswildcardPolicy == None || Subdomain ok (on the route object)?

smarterclayton · 2016-10-24T21:05:44Z

Ok with me. Any other objections / concerns from @eparis / @liggitt?

liggitt · 2016-10-24T21:12:57Z

no concerns, just a few questions:

what do we name the wildcardPolicy that wildcards the first segment of the given host?
do we add a wildcardPolicy to route.status (peer to the host field) so status reflects what the router did?
if wildcards are disabled in the router, should the router reject routes that request a wildcardPolicy other than None, or should it just ignore the requested wildcardiness and route the requested host (and report None in route.status)?

ramr · 2016-10-24T23:08:39Z

@liggitt so in response to your questions, I'd say:

i think we said Subdomain above
wasn't planning on adding an extra field. Was going to update the status for now to reflect any errors/warnings similar to the host admittance we have today - comments for 3 sorta partially fall in here as well.
Well, if we want backward compatibility, behavior should be as if its an v1.x (x < 4) router. Meaning if wildcards are disabled, ignore the requested wildcardiness but admit in the host and accordingly log that wildcards are not allowed + host admitted. Older routers would behave the same way (just won't log the complete status update re: the bit about wildcards not allowed).

liggitt · 2016-10-25T04:36:30Z

don't we want status to reflect what the router actually admitted? I'd expect wildcardPolicy to be echoed somehow in it

ramr · 2016-10-25T05:50:05Z

Was trying to get you some sample output - but am running into some issues. Please see: #11550 - maybe you have some ideas why the persisted object is missing the wildcardPolicy field.

Anyway, the intended result is the status of the route has an message that indicates what the router admitted. Routers can still override the intention that the route specifies - ala I want this route to support wildcards for the subdomain but a router with no wildcard route support would reject it but admit the host.

knobunc · 2016-10-25T18:15:09Z

Clayton, if the old router images just ignore the wildcard hostnames
(perhaps with logging) and don't break them, is that acceptable? Or is the
fact that we loosened the validation in the API alone enough to reject that
approach?

-ben

On Mon, Oct 24, 2016 at 2:52 PM, Clayton Coleman notifications@github.com
wrote:

So to summarize:

leave host as is - no validation changes

use wildcardPolicy WildcardPolicy to signal changes

Must default to None

Add at least Nested (or whatever word is appropriate if you think
there's a better domain specific one).

That's the minimal set that gets this out the door.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11201 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJkavag1uSL5grZyaGFwc_A41vegcHkXks5q3P5ygaJpZM4KNODA
.

smarterclayton · 2016-10-25T18:20:31Z

EDIT: wildly time delayed by google

The latter form isn't backwards compatible with existing servers, which is
my primary concern. We are widening validation, and suddenly an old client
/ server / router / custom integration is getting values it doesn't expect
(or worse, expected not to contain wildcards, so we expose a security
vulnerability). That means that we have broken their api compatibility
guarantee. I'm not positive the boolean is the right approach, but
widening host is not backwards compatible in a safe manner.

smarterclayton · 2016-10-25T18:29:35Z

BTW that last comment was an email from yesterday, just arriving now (thanks github).

Ben, to your question, changing validation broke the meaning of host, and changing the meaning of host (even if our router code tolerates it) can result in security risks for our customers. So we at minimum need the new field that adds behavior (but doesn't change existing behavior)

liggitt · 2016-10-25T18:32:31Z

I'd like to see clear documentation and tests around the following
ownership issues:

do we prevent wildcarding public suffixes
(e.g. *.com)?
are a specific host and wildcard host considered conflicting for
ownership purposes between namespaces (www.example.com and *.example.com )?
are a specific host and wildcard host allowed in the same namespace ( www.example.com and *.example.com, with *.example.com as a catch-all)?
can we document and make sure we have test coverage for the following
ownership scenarios:
- old wildcard host in ns1 wins over new wildcard host in ns2
- old wildcard host in ns1 wins over new specific host in ns2
- old specific host in ns1 wins over new wildcard host in ns2
- old specific host in ns1 wins over new specific host in ns2
- wildcard and specific host can co-exist in the same namespace, with
  specific host matching requests first and the wildcard acting as a
  catch-all?
- deleting a route holding *.example.com allows newer foo.example.com and
  bar.example.com routes in other namespaces to obtain those hostnames
- if foo.example.com is held by ns1, bar.example.com is held by ns2,
  and *.example.com is requested by ns3, deleting foo.example.com doesn't
  allow *.example.com to be admitted. both specific hosts must be deleted,
  and then the wildcard host is allowed.
what does the router do with wildcard routes in the API data if wildcard
support is disabled? does it treat wildcard routes as normal routes, or
does it omit them?
if a specific domain is blacklisted (www.foo.com), does admission prevent
a wildcard route (*.foo.com) that enables it anyway?
if a wildcard domain is blacklisted (*.foo.com), does admission prevent a
specific route (www.foo.com) that enables it anyway? is a wildcard
blacklist supported?

smarterclayton · 2016-10-25T18:55:32Z

EDIT: wildly delayed

a. Ram's suggestion of "Subdomain" worked for me.
b. I think we can do that in 1.5
c. I think rejection might make sense. An admin who doesn't want wildcards
is probably better to reject (with reason) than to show. That fits
"admission" better.

On Mon, Oct 24, 2016 at 5:12 PM, Jordan Liggitt notifications@github.com
wrote:

no concerns, just a few questions:

what do we name the wildcardPolicy that wildcards the first segment
of the given host?

do we add a wildcardPolicy to route.status (peer to the host field)
so status reflects what the router did?

if wildcards are disabled in the router, should the router reject
routes that request a wildcardPolicy other than None, or should it
just ignore the requested wildcardiness and route the requested host (and
report None in route.status)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11201 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pzBwB_Dpxp8ort4bRgwSiuGwrnQOks5q3R9bgaJpZM4KNODA
.

ramr mentioned this pull request Oct 4, 2016

Change haproxy router to use a certificate list/map file. #11217

Merged

bmeng reviewed Oct 9, 2016

View reviewed changes

liggitt reviewed Oct 10, 2016

View reviewed changes

ramr force-pushed the wildcard-domain branch from cf91d88 to cab98c8 Compare October 14, 2016 06:25

ramr force-pushed the wildcard-domain branch 2 times, most recently from 396ccb5 to 14ec738 Compare October 14, 2016 06:53

marun reviewed Oct 14, 2016

View reviewed changes

openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 14, 2016

dcbw added the component/networking label Oct 14, 2016

ramr force-pushed the wildcard-domain branch from 14ec738 to 76bfca2 Compare October 15, 2016 03:17

ramr changed the title ~~[WIP] Add support for wildcard domain~~ Add support for wildcard domain Oct 15, 2016

openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 15, 2016

knobunc approved these changes Oct 18, 2016

View reviewed changes

smarterclayton reviewed Oct 20, 2016

View reviewed changes

rajatchopra approved these changes Oct 20, 2016

View reviewed changes

knobunc changed the title ~~Add support for wildcard domain~~ Add router support for wildcard domains (*.foo.com) Oct 20, 2016

marun reviewed Oct 24, 2016

View reviewed changes

smarterclayton added api-approved and removed needs-api-review labels Oct 24, 2016

ramr mentioned this pull request Oct 25, 2016

Host wildcard policy for supporting wildcard routes #11550

Merged

8 tasks

ramr mentioned this pull request Nov 10, 2016

Add support for wildcard subdomains openshift/origin-web-console#853

Merged

ramr deleted the wildcard-domain branch February 2, 2017 23:55

liggitt referenced this pull request in bowei/enhancements Apr 30, 2019

Update the Ingress KEP with GA items

b2f61ab

		@@ -20,11 +20,16 @@ func RouteLessThan(route1, route2 *Route) bool {
		if route1.CreationTimestamp.Before(route2.CreationTimestamp) {

Add router support for wildcard domains (*.foo.com) #11201

Add router support for wildcard domains (*.foo.com) #11201

Conversation

ramr commented Oct 4, 2016

ramr commented Oct 4, 2016

smarterclayton commented Oct 4, 2016

preliminary feedback that would be greatly appreciated. Thx

liggitt commented Oct 4, 2016

ramr commented Oct 4, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ramr commented Oct 14, 2016

ramr commented Oct 14, 2016 • edited Loading

marun left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marun Oct 14, 2016 • edited Loading

Choose a reason for hiding this comment

marun Oct 14, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marun Oct 14, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ramr commented Oct 15, 2016

ramr commented Oct 17, 2016

knobunc commented Oct 17, 2016

ramr commented Oct 18, 2016

knobunc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rajatchopra commented Oct 20, 2016

smarterclayton commented Oct 24, 2016

smarterclayton commented Oct 24, 2016 • edited Loading

smarterclayton commented Oct 24, 2016

marun commented Oct 24, 2016

marun commented Oct 24, 2016

Choose a reason for hiding this comment

smarterclayton commented Oct 24, 2016

ramr commented Oct 24, 2016

liggitt commented Oct 24, 2016 • edited Loading

smarterclayton commented Oct 24, 2016

smarterclayton commented Oct 24, 2016

eparis commented Oct 24, 2016 • edited Loading

smarterclayton commented Oct 24, 2016

ramr commented Oct 24, 2016

smarterclayton commented Oct 24, 2016

liggitt commented Oct 24, 2016

ramr commented Oct 14, 2016 •

edited

Loading

marun Oct 14, 2016 •

edited

Loading

marun Oct 14, 2016 •

edited

Loading

marun Oct 14, 2016 •

edited

Loading

smarterclayton commented Oct 24, 2016 •

edited

Loading

liggitt commented Oct 24, 2016 •

edited

Loading

eparis commented Oct 24, 2016 •

edited

Loading

smarterclayton commented Oct 25, 2016 •

edited

Loading

smarterclayton commented Oct 25, 2016 •

edited

Loading