cloud_controller_ng
cloud_controller_ng copied to clipboard
Allow host_and_domain_taken_different_space if "path" is different
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
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.
Hi @coobr01 , thank you for submitting this issue.
Was able to repro this. Steps:
- Deploy foundation with config
disable_private_domain_cross_space_context_path_route_sharingset to true cf create-domain org cf.com- Create org
orgtwo spacesspace1andspace2 - Target
space1 cf create-route cf.com --hostname app --path app1- Target
space2 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 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.