Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The SciFi Future of Provisioner Install Commands. #326

Closed
ChrisLundquist opened this issue Jan 15, 2014 · 0 comments
Closed

The SciFi Future of Provisioner Install Commands. #326

ChrisLundquist opened this issue Jan 15, 2014 · 0 comments

Comments

@ChrisLundquist
Copy link
Contributor

So I see issues like running arbitrary commands before install and work around for configuring puppet stand alone mode along with in lined shell scripts for installs

Predicting the future is tricky business to say the least, let alone all the crazy use cases people can come up with. I'd even call it a losing bet.

I wanted to put forward the idea of factoring these parts into a maybe a files/chef_install.sh file which got uploaded automagically. Making the #install_command be essentially sh /tmp/kitchen/chef_install.sh.

Perhaps you guffaw, and say, "But, Chris! That only moves the issue around!"

In the SciFi future, where tea earl-grey is always hot, we will have a configuration variable for what script to use for the installation. Ideally, we would do that Convention over Configuration thing, where everything works great with a minimal .kitchen.yml, but lets people configure things when they need to color outside the lines.

Maybe we make a provisioner configuration variable of install_script and #install_command just executes that. Maybe if we were even more clever, we could do a few things, then call the default install script.

Far as I know, there is no good puppet installation story. Having two scripts, one for centos family, one for debian, would be a decent start, but it will never be enough. I also don't think anyone would be too resistant to move some bash out of a ruby file.

Making choices for the future is always hard. I've found having old code call new code (you know, interfaces, like we have in the case of provisioners here) is the best pattern to let the future make those choices. Fortunately, we have a great code base here, so this proposed change shouldn't be that difficult to write. I just wanted the thoughts of interested parties.

TL;DR

  • Add provisioner config var of install_script
  • Keep install scripts in files/ instead of inlined.
  • Copy appropriate install script to remote.
  • Install command invokes that script on the remote.
  • Puppet install story gets better, tea comes earl grey hot.

/cc @coderanger @fnichol

@test-kitchen test-kitchen locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant