Resolved descriptor uses wrong route if host definition is too long
Opened this issue · 1 comments
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-hostFor 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 buildI created a new space and did the deploy
cf deploy multiapps-deploy-bug.mtarThe 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
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.