I want to be able to override route from CLI

[giner]

Before domain and hostname were deprecated from manifest the following worked:

applications:
- name: hello-python-app
  memory: 64M
  instances: 1
  buildpack: https://github.com/cloudfoundry/python-buildpack
  domains:
  - dev.domain.net

To push an app user could just cf push. To push with a different name user could cf push another-name.

With the new manifest (when deprecations are taken into consideration) which looks like this:

applications:
- name: hello-python-app
  memory: 64M
  instances: 1
  buildpacks:
  - https://github.com/cloudfoundry/python-buildpack
  routes:
  - route: hello-python-app.dev.domain.net

simple cf push still works however there is no way to override the route. If we try to override with -d or -n, we get one of

The following arguments cannot be used with an app manifest that declares routes using the 'route' attribute: -d, --hostname, -n, --no-hostname, --route-path

or

Incorrect Usage: The following arguments cannot be used together: -d, --no-route

The other way around doesn't work either: if we remove routes from the manifest then simple "cf push" doesn't work. I have tried to play with substitutions however they also don't solve the problem as there is no way to set a default value.

Side notes:

1. It was a surprise that switching from buildpack to buildpacks forced us to remove "domains"
2. I think it is also a bit confusing that cli takes only domain and hostname separately but manifest only route as a whole.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/164538095

The labels on this github issue will be updated when the story is started.

[abbyachau]

Thanks for reaching out @giner, I don't have an answer right now but wanted to point out a related: https://github.com/cloudfoundry/cli/issues/1403. Why does the deprecation message stymie your workflow?

[giner]

@abbyachau

Why does the deprecation message stymie your workflow?

As soon as you change buildpack to buildpacks in manifest it's not just a note anymore, cf push starts failing.

[abbyachau]

Hi @giner thanks, changing buildpack to buildpacks should not cause cf push to fail. I'll ask the engineers to have a look at this issue. Thanks.

[tjvman]

Per this story, buildpacks is not permitted with domains (or any other deprecated manifest fields).

[abbyachau]

Hi @giner thanks for raising this issue. Are you happy to close this issue in favor of https://github.com/cloudfoundry/cli/issues/1403. If there's something we are missing here which we can help with, please let us know, thanks.

[abbyachau]

Hi @giner thanks again for reaching out. We recently sent a call for feedback about this issue. If you could please review this document, we would appreciate your feedback. Thanks.

[abbyachau]

See https://github.com/cloudfoundry/cli/issues/1403#issuecomment-536702482

[abbyachau]

Hi @giner, I've also left a comment in this document but I'm posting here so we can potentially garner additional feedback from the Community.

It would really help to get your feedback on the following. In a scenario where we support:

• a host: property and a --host override flag on v7 cf CLI which will be mutually exclusive with the --route flag below
• for the following (existing v7) manifest:

---
applications:
- name: dylan
  routes:
  - route: route.example.com
  - route: another-route.example.com

Would you require flag overrides for:

• EACH route in the manifest. This would require multiple --route override flags on push.
• OR the ability to override only the first route in the list. This would require only one --route override flag on push which will always override the first route in the list

If you require multiple --route flags on push, why and what are your use cases?

cc @selzoc @ssisil @reid47

[ahaleiii]

So... is there no way to set the route on cf push using cf cli v7 then? This is not very useful for blue/green deployment scenarios.

[reidmit]

Hi @ahaleiii , I've moved on to a different project so I may not have the latest info here, but I believe you can achieve this (and a lot more!) using manifest variable substitution. See these docs: https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html#variable-substitution

So if you had a manifest like:

---
applications:
- name: test-app
  routes:
  - ((app_hostname)).mydomain.com

You could push with cf push --var app_hostname=something, or use --vars-file if you'd like to interpolate a bunch of variables and keep them in a YAML file.

cc @Gerg to confirm/provide more up-to-date info