I would recommend checking out rove.io and puphpet.com. Both are online Vagrantfile generators. Even if you can't use their generated configurations you can look at "design patterns" they both use. They both gave me great ideas and solutions for learning Vagrant.
For example, one of these will load a .yaml file from Vagrantfile and use that for configuration information. Thanks, robo On Friday, April 10, 2015 at 9:23:31 AM UTC-7, Jim Klo wrote: > > Yes. That's close to my intent. What I wanted was the ability to pass the > name and SHA of a Git repo to be fetched by a provisioning script. There's > many ways I could do this, but was hoping for command line. Also I > wouldn't expect the provisioning script to be able to read the host ENV. > > I could do this all post provision as well in exactly the way I describe > using vagrant ssh -c "/vagrant/do-stuff.sh arg1 arg2". > > I just wanted to use the same convention consistently. I see now that's > not currently possible unless I switch to ENV. > > > Thanks, > > - JK > > On Friday, April 10, 2015, dragon788 <[email protected] <javascript:>> > wrote: > >> Ahhh, I get you now. It sounds like you are talking about using Vagrant >> provision to pass in an external script to configure your VM in a manner >> that varies from run to run. There is an open issue about "named" >> provisioners and getting that working. The intended behavior is that you >> can pass 'vagrant up --provision-with=prod' and then have a couple of shell >> scripts, one that calls "use-prod.sh" and one that calls "use-dev.sh", and >> they are "named" prod and dev. Right now the '--provision-with=' >> functionality works for calling shell or chef or ansible or whatever, but >> it doesn't work if you have two shell scripts with different names, if you >> call shell it runs both, period. >> >> Hopefully this is more along the lines of what you are looking for and >> you can follow that issue on Github. >> >> >> On Friday, April 10, 2015 at 1:56:43 AM UTC-5, Jim Klo wrote: >>> >>> >>> >>> > On Apr 9, 2015, at 4:13 PM, Alvaro Miranda Aguilera <[email protected]> >>> wrote: >>> > >>> > Hello There, >>> > >>> > Don't get frustrated and see what vagrant hast to offer.. it does help >>> a lot. >>> > >>> > But, if Vagrant is a hammer (or used as a hammer) perhaps is not the >>> > best tool for everything >>> > >>> > you may test file/shell/puppet/chef/ansible... >>> > >>> >>> True, but solving problems by adding complexity rarely works on the long >>> run. >>> >>> Puppet/chef/ansible are all fine tools, but not ideal for the tiny scale >>> I'm at. That's a lot like using a jet airplane to commute 50 miles. >>> >>> >>> > back to your point.. This has been discussed over and over and over, >>> > and you can search those in the groups or github >>> > >>> >>> Searching didn't yield many results actually - so it's hard to gauge by >>> the lack of hits that an idea has been discussed to death. >>> >>> > but basically, your first shot should be always write your own plugin, >>> > or use a separate plugin, check what vagrant triggers has to offer, it >>> > may suit you >>> > >>> >>> True - but again let's solve a problem by adding complexity? I've never >>> authored a plugin for vagrant so I can't even begin to wonder how much time >>> I'd spend figuring out how to wire up a plugin that just makes extra >>> arguments from the command line accessible from the Vagrantfile. >>> >>> >>> > ENV is very cool way to have something portable, >>> > and look at this in >>> > this way.. you set a variable outside vagrant, and vagrant >>> > transparently pass the argument to a shell script.. magic.. >>> >>> And just like the NSA, any other process in the same subshell can see >>> the "DickPic" stored in ENV too. >>> >>> I won't deny that ENV works - but it's not all that's cracked up to be. >>> You've obviously not done much IT administration on secured systems. ENV is >>> good for static state, but will get you into trouble when used as a control >>> feature. For example - bash isn't necessarily your friend with ENV - by >>> default non-interactive shells often will not cascade exported ENV like >>> interactive bash. Hence passing a value via ENV doesn't even work. Use of >>> ENV also violates the idempotent nature of the Vagrantfile file, IMO, >>> setting an ENV for one script, could unintentionally have side effects on >>> another script. It's hard to create side effects like I describe if you >>> could just pass an argument. >>> >>> Another example that vagrant users might be familiar- SALTSTACK. ENV is >>> static, as I recall, and cannot be modified during execution/parsing of the >>> YAML - all to prevent Environment Variable induced side effects. >>> >>> I can live with ENV, it solves my immediate problem. I just don't >>> believe it's the optimal solution that should be available, and just kinda >>> sad that there's no simple solution for custom command line args. I'm not >>> complainining, I'm just pointing out that with all the awesomeness that >>> Vagrant is - I'd love to see some feature consistency across commands that >>> behave in similar ways which would make it a better offering for all. IMO, >>> being able to pass arguments to a shell application that executes a script >>> command line is a very common feature. I think 90% of people would expect >>> that kind of behavior I describe by default and wouldn't expect to have to >>> do magic tricks and a lot of work to get that to work. >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Vagrant" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/vagrant-up/IxxH3f87m9M/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
