cloud_controller_ng
cloud_controller_ng copied to clipboard
Route sharing does not work
Thanks for submitting an issue to cloud_controller_ng. We are always trying to improve! To help us, please fill out the following template.
Issue
Shared route cannot be used in the space it has been shared with.
Context
When creating a route in space A, sharing it with space B through /v3/routes/:guid/relationships/shared_routes and trying to map it to an app in space B the error Routes cannot be mapped to destinations in different spaces is sent back by the API. This happens when specifying the route in the app manifest and then pushing the app as well as when creating the app manually and using the map-route command.
Steps to Reproduce
DOMAIN=<your domain>
cf enable-feature-flag route_sharing
cf create-org test-org
cf create-space -o test-org test-space
cf create-space -o test-org test-space-2
cf target -o test-org -s test-space
cf create-route "$DOMAIN" --hostname test-app
SPACE_2_GUID=$(cf space test-space-2 --guid)
ROUTE_GUID=$(cf curl "/v3/routes?space_guids=$(cf space test-space --guid)" | jq -r .resources[0].guid)
cf curl -X POST "/v3/routes/$ROUTE_GUID/relationships/shared_spaces" -d '{"data":[{"guid":"'"$SPACE_2_GUID"'"}]}'
cf target -o test-org -s test-space-2
cf routes
cf create-app test-app
cf map-route test-app "$DOMAIN" --hostname test-app
Expected result
Route can be mapped to an app in the space, the route has been shared to.
Current result
The route cannot be mapped:
$ cf map-route test-app "$DOMAIN" --hostname test-app -v
[...]
Mapping route test-app.****** to app test-app in org test-org / space test-space-2 as admin...
REQUEST: [2022-08-08T13:49:36Z]
POST /v3/routes/0b2f1684-b04c-49e9-ae41-726a145c19f4/destinations HTTP/1.1
Host: *****
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: cf/8.4.0+b4c083e.2022-06-02 (go1.17.10; amd64 linux)
{
"destinations": [
{
"app": {
"guid": "0bd4f299-cf07-403b-8f5e-b9b4ee554c57"
}
}
]
}
RESPONSE: [2022-08-08T13:49:36Z]
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json; charset=utf-8
Date: Mon, 08 Aug 2022 13:49:36 GMT
Referrer-Policy: strict-origin-when-cross-origin
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload;
Vary: Accept
X-B3-Spanid: 3f9588680d21c86e
X-B3-Traceid: 61b6b9cd642e840f3f9588680d21c86e
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Runtime: 0.027332
X-Vcap-Request-Id: 870a3eaa-028f-4ae1-5eef-d125207493b3::da15729d-a1d7-4c5c-87e3-81197ae2081f
X-Xss-Protection: 1; mode=block
{
"errors": [
{
"code": 10008,
"detail": "Routes cannot be mapped to destinations in different spaces.",
"title": "CF-UnprocessableEntity"
}
]
}
Routes cannot be mapped to destinations in different spaces.
FAILED
This PR needs to be merged for this to work: https://github.com/cloudfoundry/cloud_controller_ng/pull/2904
I would suggest we add features only into the documentation if they are already working. It's mentioned here: http://v3-apidocs.cloudfoundry.org/version/3.122.0/index.html#share-a-route-with-other-spaces-experimental
Currently, we have been using the the experimental tag to denote the feature is in active development. I felt that tagging experimental on this share route endpoint seemed reasonable since the endpoint technically works.
I don't have any strong opinion this though and am open to discussing this further here or in CAPI office hours tomorrow
For me a feature which is described in the documentation, even it is marked as experimental, should be something like a MVP. So it should bring some kind of value to users and enable them to try it out. Of course the actual sharing of the route to another space works, but as you cannot display, nor use it there, it is not of any value to do so at the moment.
Experimental features mean to me that they might not be in its final version, be buggy, have performance or security issues, have breaking changes and might be removed without further notice in future releases, so users should not rely on them.
Just for indicating that something is under development I'd prefer something like "Coming soon" or so and leaving out the API path and parameters, so users don't start trying it out, before it is actually of any use.
Mapping shared routes to apps should work now, as the PR was merged. Closing this issue.