destination-port/app-port should be configurable in map-route like with the new beta flag for destination-protocol/app-protocol #3613
Description
Please provide details on the following items. Failure to do so may result in deletion of your feature request.
What's the user value of this feature request?
Users can directly map routes to custom app ports, e.g. for Docker apps with multiple ports, via cf cli without having to patch the destinations array via API call later on.
This would simplify this documented process: https://docs.cloudfoundry.org/devguide/custom-ports.html
to a simple map-route command like comparable to the beta flag for HTTP/2 protocol routes:
https://docs.cloudfoundry.org/adminguide/supporting-http2.html#application
Who is the functionality for?
Customers who use docker apps with multiple ports that should be exposed as different routes and
customers who need to expose a non-standard (8080) port for buildpack apps and a different port than the lowest port for docker apps.
How often will this functionality be used by the user?
Hard to say, once for these special apps.
Who else is affected by the change?
No breaking change as just another parameter is added and it is completing the destination object fields (besides the recently added destination-protocol as app-protocol map-route parameter now just the destination-port as app-port parameter is missing).
Is your feature request related to a problem? Please describe.
It is a very inconvenient and error-prone process to get the route GUID for the app with the wrong default port at first and then patching it with the API switching context and involving several steps even with cf curl.
Describe the solution you'd like
I have a proposal running in the https://github.com/funcf/cli repo on the main branch there.
The PR to include it was this one: funcf#1
Actually this fork was created to contribute to this feature and other CF CLI enhancements. :-)
I actually created a PR to this repo by accident first and closed it directly, because I did not want to bother anyone with a PR that does not follow the description template from the start: #3612
But if that is the fastest path, then I can fix the pre-conditions and we can reopen it with an updated description.
Describe alternatives you've considered
After the CF Day Europe @itsouvalas and I hacked on this issue and this simple extension following the example of the destination-protocol as app-protocol parameter was the most obvious case so we did not consider other paths.
Since there is another open issue (#3606) stating that the parameters are not matching the docs (where sometimes destination-protcol was mentioned instead of app-protocol as parameter), we could consider to refactor both to destination-* - however, that would align it more with the CF API on the one hand, but also introduce a breaking change. It is stated in the cli help that it might change at any time - but app-* as a prefix might also be fine (and shorter) and updating the docs is faster as well.
Additional context
Note:
As of the GA of the v7 CLI, the v6 line is no longer under active development and will be updated only to patch CVEs or fix severe blocking defects with no workarounds.