Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add experimental destination-protocol flag to map-route #2192

Merged
merged 1 commit into from
Aug 19, 2021

Conversation

mariash
Copy link
Member

@mariash mariash commented Aug 18, 2021

Allows users to specify HTTP2 protocol can be used to reach application.

Does this PR modify CLI v6 or v7?

V8

Description of the Change

Adding --destination-protocol flag to the map-route cli command. This will allow users to use HTTP2 protocol to communicate with their apps. It sets the protocol property in the map route destination in Cloud Controller which is passed to the Diego LRP and advertised to Gorouter. By default if destination-protocol is not set HTTP1 protocol will be used for HTTP route. We extended the validation when map-route is used for existing route: if everything is the same except for the destination protocol the error will be raised.

This command is documented in map-route command help message as an experimental command. We have not decided yet how this will be displayed for users in routes or another command. So there is a possibility that this flag name might change in the future.

Why Is This PR Valuable?

Users will be able to use CLI to activate HTTP2 protocol to access their applications.

Why Should This Be In Core?

This is a core functionality of the route destination.

Applicable Issues

#2188
cloudfoundry/routing-release#200

How Urgent Is The Change?

We want to include this in V8.

Other Relevant Parties

@ctlong @Gerg

@ctlong
Copy link
Member

ctlong commented Aug 18, 2021

Steps to test:

  • Claim an env
  • Upload capi-release with this cc_ng PR
    • (This will not make e2e http2 work, but is enough to test this CLI command)
  • Push an app, curl GET /v3/routes/:guid/destinations, and validate the response includes "protocol": "http1"
  • Run cf map-route APP_NAME DOMAIN --hostname HOSTNAME --destination-protocol http2 with the same inputs for DOMAIN and HOSTNAME that the push used, and validate that the response is an error due to a pre-existing route mapping with a different protocol
  • Unmap the route on the app
  • Run cf map-route APP_NAME DOMAIN --hostname HOSTNAME --destination-protocol http2 with the same inputs as before and see it succeed
  • curl GET /v3/routes/:guid/destinations, and validate the response includes "protocol": "http2"
  • Create a new route, and then map your app to that route with --destination-protocol tcp and see it fail with an error related to trying to set tcp as the protocol for an http route
    • If you want to be really thorough you could do this again but with a tcp route and --destination-protocol http1
  • Create a new route, and then map your app to that route with --destination-protocol fake-protocol and see it fail with an error related to trying to needing a real protocol

Allows to specify HTTP2 protocol that is used to reach application.

cloudfoundry#2188

Co-authored-by: Maria Shaldybin <mariash@vmware.com>
@JenGoldstrich
Copy link
Contributor

Looks good to me, merging with the update that Carson listed above, tested it manually with @ctlong, @mariash, and @jdgonzaleza

Still open questions about int testing of the http2 feature in CF but that can be solved in another PR

@JenGoldstrich JenGoldstrich merged commit d01e549 into cloudfoundry:master Aug 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

As a **app developer**, I can **set route destination protocols** when **mapping routes on the v8 CLI**
4 participants