Assumption about the cf deployment manifest.

[simonjohansson]

In scripts/generate-deployment-manifest

spiff merge \
  ${manifest_generation}/config-from-cf.yml \
  ${manifest_generation}/config-from-cf-internal.yml \
  ${deployments}/cf.yml \
  > ${tmpdir}/config-from-cf.yml

We make an assumption that the deployment manifest is called cf.yml for cf.
In my installations I call the manifest by version.

➜  manifests git:(master) ✗ ls
178.yml  183.yml  187.yml  192.yml  194.yml  195.yml  196.yml  197.yml  199.yml  200.yml  203.yml  205.yml  207.yml  208.yml  209.yml  210.yml

Would you guys/gals be open for a PR to take a path to a manifest rather than a path to a dir where path/cf.yml must be present?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/95425084.

[amitkgupta]

Hi @simonjohansson,

The current assumption is not ideal, but it is intentional. At some point, we'd like to improve manifest generation strategies across the various Cloud Foundry teams, making things more consistent, easier to reason about, safer, and in a way that plays well with the typical use case where a single director is managing multiple deployments and usually there's a repo or directory for that "environment" containing all the relevant stubs and manifests. The reason for this particular assumption was to make it so the interface to the generate-deployment-manifest script is generic and release-agnostic. It takes in various things like IaaS settings and property overrides, that can make sense for any release, and then expects a directory with manifests of any upstream deployment dependencies. Although the current script only uses config-from-cf.yml, the idea is that the manifest-generation could have multiple such templates, and the manifest generation script could pattern match on config-from-X.yml, and loop over all the X, looking for X.yml in the upstream deployments directory.

The current approach needs refinement, but it's the general direction we want to go in.

Most people/teams who don't have a cf.yml are simply making a symlink to make this work.

[simonjohansson]

Okok, thanks for the explanation, that all makes sense.

Symlink it is!