cloud_controller_ng icon indicating copy to clipboard operation
cloud_controller_ng copied to clipboard

Allow host_and_domain_taken_different_space if "path" is different

Open coobr01 opened this issue 4 years ago • 3 comments

Issue

We have multiple spaces for different applications in our cloud foundry ORG, we'd like to setup a common route having a different path in each space. The ultimate goal is to avoid using a reverse proxy to provide a common subdomain across all applications no matter which space they are associated with.

In SPACE A common.app.cf.com/app1

In SPACE B common.app.cf.com/app2

In SPACE C common.app.cf.com/app3

Steps to Reproduce

cf7 map-route APPNAME DOMAIN --hostname COMMONHOST --path app{1,2,3}

Expected result

I'd like to be able to reuse the same route (w/ path difference) across spaces in at least the same DOMAIN.

Current result

domain_id and host host_and_domain_taken_different_space

Possible Fix

Remove check in https://github.com/cloudfoundry/cloud_controller_ng/blob/main/spec/unit/models/runtime/route_spec.rb

coobr01 avatar Mar 26 '21 17:03 coobr01

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/177513903

The labels on this github issue will be updated when the story is started.

cf-gitbot avatar Mar 26 '21 17:03 cf-gitbot

Hi @coobr01 , thank you for submitting this issue.

Was able to repro this. Steps:

  1. Deploy foundation with config disable_private_domain_cross_space_context_path_route_sharing set to true
  2. cf create-domain org cf.com
  3. Create org org two spaces space1 and space2
  4. Target space1
  5. cf create-route cf.com --hostname app --path app1
  6. Target space2
  7. cf create-route cf.com --hostname app --path app2

Results in error:

Creating route app.cf.com/app2 for org org / space space2 as admin...
domain_id and host host_and_domain_taken_different_space
FAILED

This only happens if your foundation has the config disable_private_domain_cross_space_context_path_route_sharing set to true, which was created for a security concern. If this is set to false, the above will not error out.

Looking at the original story, this scenario is implemented as intended:

Example Scenario 4

Exists in space 1 - space1.mydomain.com/my-path
Space 2 tries to create - space1.mydomain.com (with no path or with a different path) - this should fail

Now, I'm not sure why we didn't allow this case. It's possible it was too complicated at the time to prohibit shadowing different paths while still allowing distinct paths. We will have to do some digging to see if there are other reasons this case was implemented as such.

sethboyles avatar Mar 26 '21 21:03 sethboyles

@sethboyles Thanks for taking the time to read and respond. Its a bit of "squatters rights", first one in gets it. I can see why this setting can be controversial. What I'd like to see though is a way to control this at an ORG level (not at the foundation level). I wouldn't trust different SPACES in a separate ORG to be able to use the same private domain but I would like spaces in my own ORG to be able to share. Based on your foundation reference, this setting seems much wide open and that I'm looking for something a bit more locked down but still flexible.

coobr01 avatar Mar 26 '21 22:03 coobr01