Look at deprecating this script

[jhunt]

Should we continue to maintain this script, since we have the jumpbox-boshrelease? I would be in favor of deprecating this repo and urging people to go use the BOSH release.

[jhunt]

@geofffranks / @dennisjbell thoughts?

[mkb]

There is plenty of call for jumpboxen not created by bosh, no?

[dennisjbell]

There may be need for this script for companies that already have bastion hosts that just need these extra utilities/apps/libs that can't use bosh-created bastion hosts. -- thinking of enterprise-level companies that have different organizations that provision/own them.

[jhunt]

@mkb: I don't personally think so; having a jumpbox with all the amenities, that BOSH keeps running is kind of nice.

@dennisjbell: in those circumstances, we've been unable to / prohibited from adding our own stuff to the jumpboxen, so the script is of limited usefulness in those scenarios.

[bodymindarts]

In codex this script is used to run on the terraform provisioned bastion. How is it possible to provision a jumpbox with BOSH when the BOSH needs to run behind a dmz and the only way to create it is from a jumpbox?

[krutten]

In discussions with Dennis, one train of thought was to use this as part of the bootstrapping then replace it with the Boshrelease version as part of the standup. Being able to boot the bastion move much of the work to the instance and VPC instead of MacOS, but we have two scripts to maintain.

Maybe a solution would be to refactor the jumpbox-boshrelease to have the "standalone" script wrapper available, able to provision a compatible AMI, then run the the bosh script as bosh would. Only one "script" to maintain, and the pre-bosh and post-bosh jump boxes would look virtually identical. You would just pass the AWS private key in to connect, and it would loop through the users section to create login's

[jhunt]

It was just a thought, you guys.