You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 essentiallysh /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
install_script
files/
instead of inlined./cc @coderanger @fnichol
The text was updated successfully, but these errors were encountered: