manifest changes aren't deployed

[afeld]

Since the manifest is pulled from the running application, any changes to the local manifest aren't actually included in the push.

Have a note in the README, but should really figure this out.

/cc #6

[Snugug]

Why can't you use the manifest file in the repo?

Maybe check to see if manifest.yml exists and, if it doesn't, pull from the application?

[afeld]

For the main application I work on, for example, the manifest isn't complete, so (as it stands) we couldn't use that approach. While maybe not ideal, I imagine this is the reality for many applications deployed to CF.

Opened an issue with an idea around this in a related project: contraband/autopilot#11

[jmcarp]

@afeld: why isn't the manifest for that project complete? Are there settings that can't be specified in the manifest? I think the approach that autopilot takes--treating the manifest as the source of truth for desired application state--is the way to go:

• It guarantees reproducible deploys
• It requires developers to store configuration in one place
• It prevents anti-patterns like storing secrets in environment variables (prefer user-provided services)

I would actually argue that supporting deploys without a complete manifest does more harm than good--why not require users to configure applications properly?

[afeld]

The only things that aren't in the manifest are sensitive environment variables. While we can/should move those to user provided service instances, some gems (like New Relic's) read directly from specially-named environment variables, and I haven't tried to figure out a workaround.

[jmcarp]

I've tried two approaches for passing credentials from user-provided services into tools that expect to find their configuration in environment variables:

• The quick hack: copy all credentials in services into the environment. See https://github.com/18F/openFEC/blob/develop/webservices/setenv.py.
• The less hack-y but verbose approach: invoke new relic (or other services) in application code, explicitly passing credentials from user-provided services. See https://github.com/18F/fec-cms/blob/master/fec/fec/wsgi.py#L19-L24.

Either approach could be documented or extracted for reuse. There's also a nice helper library for node for inspecting CF environment variables, including services: https://github.com/cloudfoundry-community/node-cfenv. If analogous tools don't already exist for ruby, python, etc., we can port the node version ourselves.

Point being: it's worth figuring out a few details about user-provided services if it buys us reproducible builds and helps avoid brittle string parsing.

cc @dhcole, since you've posted some issues on this repo. If we're willing to treat the manifest as the ground truth for configuration, lots of issues get fixed for free. This is also exactly what https://github.com/concourse/autopilot does, so we wouldn't have to maintain our own zero-downtime deploy tool.