Feature-request: bosh releases should be able to perform post-install actions on the CLI machine

[evanfarrar]

BUCC is really cool. It has one thing in particular that is a super power I'd like to give to all things BOSH: after you install Concourse, you are configured to use Concourse.

Here's what it is normally like:

1. run this command to install concourse
2. now interrogate credhub to figure out what secrets/infrastructure were generated
3. use the results of that interrogation to log in to concourse and fly set-pipeline

What if it were like this:

1. run this command to install concourse:bosh deploy -d concourse -v target-name=myconcourse
2. fly -t myconcourse set-pipeline --pipeline my-pipeline --config pipeline.yml
3. There is no step three.

This same concept applies to CFAR and the CF cli, and to CFCR and the kubectl cli. This would be something to run locally after the whole release is resolved, possibly after the whole manifest has successfully deployed.

Risks/Challenges/Thoughts:

• well, for starters, this is probably somewhat operating system specific. The process by which I target concourse on Windows is probably different than on Linux.
• This is so convenient that I will want to re-enter it, so I may want to run just the local-post-deploy hooks in a release.
• This almost necessarily involves secrets, and a lot of baggage comes along with that: what if I don't want this written to disk? What if it is rotated while I'm trying to use it?
• In addition to implicit targeting One MVP iteration of this would be to simply output to screen the whole host of variables you need to log into your concourse:

Thanks for installing concourse! Run this to log into your concourse:
fly -t myconcourse --api https://54.172.12.7 --password qwertyuiop --user admin

[rkoster]

Have been thinking about this space for a while, and don't really like the idea of the bosh cli having to know about fly. But there is definitely a use case for wanting to use generated secretes to authenticate with the just deployed service. What I really like are the bbl print-env and bucc env commands. Which can be sourced into the active shell. So maybe a release could keep a record of environment variable to secrete mappings. Which would allow a bosh -d concourse print-env. Then we might have to make a PR to fix fly to accept env vars, but many cli's already do.

[evanfarrar]

Well, I wasn't exactly suggesting that BOSH itself know about fly, but that all release authors could add a specific file to a specific place which would be invoked by bosh deploy or bosh -d concourse print-env.

True, doing just variable values and asking users to source/eval it seems mega useful and narrowly defined, but there are other useful things I could think of wanting to do that might warrant making this a script:

1. add a private key for a jumpbox you just deployed to the ~/.ssh directory, or to ssh-agent
2. install the CLI (fly) to /usr/local/bin
3. save an director "environment" to ~/.bosh/
4. add an SSL key to your keychain

Another tactic that we could use is to run a sub-shell or take a command that has the env set, so that the user doesn't need to eval (something we considered doing in BBL):

bosh set-env -d myconcourse -e "fly -t myconcourse"

[dpb587-pivotal]

This is kind of what I was trying to brainstorm in cloudfoundry/bosh-cli#402 for how to integrate local provisioning, possibly through links.

[evanfarrar]

Ahhh I knew we talked about this somewhere, happy to close and re-open there.