Resolved descriptor uses wrong route if host definition is too long

[cuhland]

Description

When a application has defined a host parameter which is too long (it looks like 64 characters are the boundary) and the definition of the provides property is using url: '${default-url}' then the url will be truncated using the first 56 character of the host definition + 8 (random) characters.

See also resolved deployment descriptor in MAIN_LOG

"parameters" : {
  "default-url" : "https://000000000000000000000000000000000000000000000000000000000000000-more-than-64.cfapps.eu10.hana.ondemand.com",
  "default-uri" : "000000000000000000000000000000000000000000000000000000000000000-more-than-64.cfapps.eu10.hana.ondemand.com",
  "app-name" : "backend",
  "protocol" : "https",
  "domain" : "cfapps.eu10.hana.ondemand.com",
  "host" : "00000000000000000000000000000000000000000000000000000006ba5e791"
}

In the resolved deployment descriptor the MAIN_LOG also shows the resolved endpoint for the broker service configuration

"SBF_SERVICE_CONFIG" : "{\n  \"backend\": {\n    \"extend_credentials\": {\n      \"shared\": {\n        \"endpoints\": {\n          \"backend\": \"https://000000000000000000000000000000000000000000000000000000000000000-more-than-64.cfapps.eu10.hana.ondemand.com\"\n        }\n      }\n    }\n  }\n}\n"

But the resolved endpoint is not the defined route of the application.

Your environment

• MultiApps CF CLI Plugin version - 2.1.2
• which CF vendor is used - SAP (cfapps.eu10.hana.ondemand.com)

Steps to reproduce

I created a example project with this mta.yaml

ID: multiapps-deploy-bug
_schema-version: '3.1'
parameters:
  deploy_mode: html5-repo
version: 0.0.1

modules:
 - name: backend
   type: java
   path: backend
   parameters:
      host: 000000000000000000000000000000000000000000000000000000000000000-more-than-64
      memory: 1024M
   build-parameters:
      builder: maven
      timeout: 15m
      build-result: target/*.jar
   provides:
    - name: backend
      properties:
         url: '${default-url}'

 - name: broker
   type: nodejs
   path: broker
   parameters:
      host: ${app-name}-${space}
      memory: 1024M
      create-service-broker: true 
      service-broker-name: ${app-name}-${space}
      service-broker-user: "BrokerUser"
      service-broker-password: "SomeFancyBrokerPassword!"
      service-broker-url: ${default-url}
      service-broker-space-scoped: true
   build-parameters:
      ignore: [".gitignore", manifest.yml, "*.mtaext", "mta.*", "*.mtar", ".mta/"]
      timeout: 15m
   properties:
      SBF_CATALOG_SUFFIX: ${space}
      SBF_ENABLE_AUDITLOG: false
      SBF_BROKER_CREDENTIALS: >
        {
          "BrokerUser": "SomeFancyBrokerPassword!"
        }
      SBF_SERVICE_CONFIG: >
        {
          "backend": {
            "extend_credentials": {
              "shared": {
                "endpoints": {
                  "backend": "~{backend/url}"
                }
              }
            }
          }
        }
   requires:
   - name: backend
   - name: uaa
   - name: html5-host

resources:
 - name: uaa
   type: com.sap.xs.uaa
   parameters:
      service: xsuaa
      service-plan: broker
      shared: true
      config:
         xsappname: uaa-${space}
         tenant-mode: "dedicated"
         scopes:
         - name: "uaa.user"
           description: TODO what does this scope do?"
         role-templates:
         - name: "Token_Exchange"
           description: TODO what does this role template do?"
           scope-references:
           - uaa.user
 - name: html5-host
   type: org.cloudfoundry.managed-service
   optional: true
   parameters:
      service: html5-apps-repo
      service-plan: app-host

For the creation of the MTAR is used the Multi-Target Application Archive Builder in Version 1.1.19 from here

java -jar mta_archive_builder-1.1.19.jar --build-target=CF build

I created a new space and did the deploy

cf deploy multiapps-deploy-bug.mtar

The log for that was

Detected MTA schema version: "3"
No deployed MTA detected - this is initial deployment
Detected new MTA version: "0.0.1"
Service "uaa" exists but doesnt have any bound applications
Service "html5-host" exists but doesnt have any bound applications
Processing service "html5-host"...
Processing service "uaa"...
Updating service "uaa"...
Creating application "backend" from MTA module "backend"...
Uploading application "backend"...
Scaling application "backend" to "1" instances...
Staging application "backend"...
Application "backend" staged
Starting application "backend"...
Application "backend" started and available at "00000000000000000000000000000000000000000000000000000006ba5e791.cfapps.eu10.hana.ondemand.com"
Creating application "broker" from MTA module "broker"...
Uploading application "broker"...
Scaling application "broker" to "1" instances...
Staging application "broker"...
Application "broker" staged
Starting application "broker"...
Application "broker" started and available at "XXX"
Updating service broker "broker-cuh-test"...
Skipping deletion of services, because the command line option "--delete-services" is not specified.
Process finished.
Use "cf dmol -i 184392687" to download the logs of the process.

Additional information

The MAIN_LOG can be found here

[valentinEmpy]

Hi,

There is a natural limitation by CF as such:

host must be no more than 63 characters

This could be observed when trying to manually map a long route using 'cf map-route':

Server error, status code: 400, error code: 210001, message: The route is invalid: host must be no more than 63 characters

However, as it is often relied on the organization name and space name to generate the default route for the application it is a necessity to have this feature as it enables deployments in organizations/spaces with long names which would otherwise not be possible due to above limitations.

As observed, the host validation includes length checks and correction by truncating and appending the hashcode as hex string in order to generate a shortened host. This same logic carried over to the explicit definition of 'host' parameter in the deployment descriptor as well.

It would make sense to stay consistent with CF and fail accordingly if 'host' is explicitly used in the deployment descriptor and sustain the above logic only for the default generation of the route. That way, the application will not be started on a route which is not expected by the end user and instead would fail the deployment (CC call failure) when trying to map the route to the application. This is a future possibility but I'd rather say it depends on the need of this change in logic and actual simplicity of the implementation.