'host' deprecated in manifest - how to emulate with 'routes' and variables?

[drnic]

The latest CLI is noting that host, domain etc are deprecated in manifests, and instead we should use routes. The latter routes requires a full subdomain.domain.com known in advance which is unfortunate for sample applications or "ready-to-deploy-to-your-cloudfoundry" aplications.

For example, https://github.com/cloudfoundry-incubator/stratos/blob/4e15499bb3f9cd4779f44b6e0a1388ed8aeda3f8/manifest.yml#L5

Is there an equivalent method for achieving this, whilst using routes?

If not, could I propose that cf includes some functional variables that will be calculated at cf push time if not provided by users?

E.g ((shared_domain)) could be automatically resolved to the first shared domain.

The stratos example above could then be changed to:

applications:
  - name: console
    memory: 1512M
    disk_quota: 1024M
    timeout: 180
    buildpack: https://github.com/cloudfoundry-incubator/stratos-buildpack#v2
    health-check-type: port
    routes:
    - route: console.((shared_domain))

[cf-gitbot]

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

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

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

[dkoper]

Hi @drnic

I would have thought that the equivalent would be to simply omit host and routes attributes. Without those, cf CLI would create & map a route for you, which consists of the app name with the first shared domain.

The idea was that most use cases would be either you want a particular route, so specify it in full under routes, or you are not too picky, in which case don't specify anything and you'll get a default route.
Note that to get no route (which has plenty of valid use cases, but in CF's world has always been a minority), you (still) explicitly set no-route: true, and to avoid clashes when teaching a class on CF and have everybody deploy the same app to the same space, you (still) use random-route: true.

Regards, Dies

[drnic]

@dkoper what is/was the plan for communal apps that are deployed to many CFs across many orgs such as https://github.com/cloudfoundry-incubator/stratos/blob/v2-master/manifest.yml#L5 - here host: console means https://console.your-domain? Perhaps we don't want to deprecate host:?

[abbyachau]

cc @zrob for visibility

[abbyachau]

cc @shalako @shubhaat for visibility

[abbyachau]

In CLI V7, manifests will be handled server side. @ssisil @tcdowney (CAPI PM and Anchor) please see this issue for consideration regarding deprecated manifest values.

[tcdowney]

Hi @drnic, just wanted to share some additional context and address some of these concerns.

As Abby mentioned, the upcoming v7 version of the cf cli will be using the new CAPI server-side app manifest feature that we began work on last year. There are several benefits to parsing and applying manifests on the API itself, including:

1. Clients (cf cli, Java client, etc.) won't have to roll their own (divergent) manifest implementations.
2. CAPI can add new features to the manifest as they become available on the API without requiring clients to do this work after the fact.

As part of doing this, we deprecated some of the manifest properties that either don't make sense server-side, have been supplanted by new, more general fields (e.g. singular buildpack -> buildpacks array), or represent CLI-specific workflows that CAPI currently doesn't support.

Currently, host, domain, etc. fall into this last category. While the CLI has the concept of a "default" shared domain that it selects by choosing the first domain that is returned by the API, Cloud Controller itself doesn't have a concept of a "default" domain. Given that, we're hesitant to make assumptions about what domains should be chosen when the user does not specify one in these cases. If we were to add something like a platform or org-scoped default domain and I could see us potentially supporting this use-case in the future, but right now this is the state of things (cc @Gerg and @ssisil about this potential use-case for default domains).

That being said, the v6 CLI will continue to support these properties as it always has. Users won't have to make any changes to their manifests or cf push flows until they make the conscious decision to upgrade to the v7 CLI and at that time they'll likely have to make other (hopefully minor) adjustments as well. I'd expect these users to either adjust the manifest to what they want, manually map the route, or supply the shared domain themselves using manifest variable substitution.

Thanks for pointing out this use-case to us and I hope this helps clarify where we're currently at on it.

---

Also as an aside, I just realized that the random-route: true param we support server-side is picking the first SharedDomain which contradicts what I said above. 😖

https://github.com/cloudfoundry/cloud_controller_ng/blob/9c54db1b68aecbff5655001b2c1fb8dc1814e562/app/actions/app_apply_manifest.rb#L77

I think there may be some subtle bugs due to that (which I'm going to poke at), so I'd still want to wait on us having a good default domain story before considering adding back support for something like host.

[giner]

... I'd still want to wait on us having a good default domain story ...

Depending on implementation default domain may not play well with isolation segments or the case where different domains serve different purposes.

[tcdowney]

@giner some ideas around "default domains" are being discussed in this proposal for V3 Domains.

I think the current thinking is that v3 Organizations will have a link to their default domain which will either be a global platform default or a default specific to that organization. For orgs in isolation segments operators should configure them to have a domain that is applicable for the isolation segment that the org belongs to. For different domains with different purposes, this default domain concept should still be an improvement over the CLI's current "first domain in the list is the default" approach.

[giner]

Thank you @tcdowney, left a comment on the document.

[abbyachau]

Hi @drnic 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]

Currently blocked on review with the CC API team, who owns the manifest in v3/v7. For routes, we'll need to think about how they are able to change the manifest since the property is a list of routes and overriding a particular route using a flag will require changes to the manifest. Also blocked on adding a host to the manifest, which will not work in conjunction with the routes property.

[abbyachau]

Hi @drnic , thanks again for this issue.

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

[drnic]

github + projects' documentation is full of sample and shared applications for people to deploy to their own CF installations. Each CF will obviously have different shared domains.

Therefore these pre-created applications cannot include fully-defined routes in their manifest.yml.

I would like a solution to how a sample/shared application can be pushed to all CF installations without the documentation having beg the user to first "find out what your shared domain is" and then "update the manifest.yml to edit the routes". If we take our user base down this dark path of awkward tutorials, it will be upsetting.

[davidje13]

@tcdowney I'm a little confused by your explanation; could you clarify how specifying host differs in the new world from simply not specifying any route at all (i.e. relying on the default <appname>.<primary-domain>)? It was my understanding before that specifying host just overrode the <appname> in that calculation.

[tcdowney]

@davidje13 my comment was specific to what the V3 "serverside" app manifest would do with that information. Right now the Cloud Controller API will not do anything around routes if you do not specify routes in the server-parsed app manifest. At the time I wrote that there was no concept of a "primary" or "default" domain on the API -- it was purely something that the CLI did by inferring that the first domain returned from the api was "primary."

When the CLI owned the parsing/understanding of the app manifest it did what you say.

This all has changed a bit since I wrote that comment last year. Organizations in V3 now have the concept of a "default domain" (see the link on V3 org response https://v3-apidocs.cloudfoundry.org/version/3.79.0/index.html#the-organization-object) and I could see the serverside manifest potentially taking advantage of this information.

I don't work on the API anymore, so looping in @Gerg @selzoc who may be able to speak more on the current (and potential future) state of things.

[victory-glitch]

Yes, please add a host option of some type for the v7 api so we don't need to hack it with variable substitutions. We run private instances of cloudfoundry on different servers (each with its own domain), and our apps have unique routes via <modified-appname>.<server-domain>. Using the host: <modified-appname> variable allows us to easily manage the route names when deploying apps to different servers with different domains.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed.

[joaopapereira]

Some work was done on newer versions of CC API with changes on manifests that allow the user to say they want a random route or if they want a default route to be created based on the name of the app. Please check https://v3-apidocs.cloudfoundry.org/version/3.178.0/#manifests for more information.

I am going to close this issue based on the above paragraph. Please check if the latest CLI v8 version addresses yll's concerns if not please create a new issue with more information.