I had originally thought "push" was like "provision" -- that it could be done in a customized-to-the-vm way. Nope, I'm wrong! So then it makes sense that the "push" block isn't called multiple times, even if called at the top level.
So then if I want it to do multiple things for multiple different VMs, I need to make it handle the multiple VMs itself. But is there a way to query what the provider (e.g. virtualbox, aws, etc.) of the current VM(s) is/are? I suppose push doesn't have the "vagrant provision"-style thing where you can just do it for one VM unless you build it yourself. Maybe the right answer is for me to parse the output of "vagrant status" and only push to VMs that are currently running if I want a multi-VM-aware push. I like the idea that "vagrant push" lets users have a dead simple way to push an app. But if it's going to be dead simple for the users, I need it to be smart and complicated on my end, at least for multi-VM setups that can be deployed to multiple providers. It should be possible to push just to one app server or to both, etc. On Sun, Mar 8, 2015 at 12:47 AM, Alvaro Miranda Aguilera <[email protected]> wrote: > Hello, > > Not sure if this is what you are after? > > static:multipush kikitux$ vagrant push db > static:multipush kikitux$ vagrant push web > > static:multipush kikitux$ vagrant push > The Vagrantfile defines more than one 'push' strategy. Please specify a > strategy. Defined strategy names are: > > ["web", "db"] > > > the scripts are run locally on the box, so you can call whatever > command you require.. here I am just doing date > file > > Vagrant.configure("2") do |config| > #next will run in all instances, since is config.* > config.vm.provision "shell", inline: "echo Hello" > > config.vm.define "web" do |web| > web.vm.box = "hashicorp/precise64" > #next will run only on web, since is web.* > web.vm.provision "shell", inline: "echo Hello from $HOSTNAME" > end > > config.vm.define "db" do |db| > #next will run only on db, since is db.* > db.vm.provision "shell", inline: "echo Hello from $HOSTNAME" > db.vm.box = "hashicorp/precise64" > end > > config.push.define "web", strategy: "local-exec" do |push| > push.inline = <<-SCRIPT > date > web > SCRIPT > end > > config.push.define "db", strategy: "local-exec" do |push| > push.inline = <<-SCRIPT > date > db > SCRIPT > end > > end > > > On Sun, Mar 8, 2015 at 5:51 PM, Noah Gibbs <[email protected]> > wrote: > > Hey, folks! That's much to all the Hashicorp folks and Vagrant > contributors. > > I've been working more with Vagrant lately, and I'm repeatedly surprised > at > > how well the API works. Appreciate it! > > > > This may be in the documentation. If so, I couldn't find it, and mea > culpa. > > > > Let's say you're using multiple VMs. For example, say there are two > > (different) app servers and a DB server. We want these to be compatible > with > > both VirtualBox and AWS provisioners, so we won't always have an IP > address > > of 127.0.0.1 that works. > > > > When you're writing a top-level config.vm.provision or config.push block > in > > your Vagrantfile, is there any way to tell which VM it's being invoked > for? > > For instance, it would be nice to be able to write a top-level Chef > > provisioner that loaded the config out of a JSON file, but used a > different > > JSON file for each app server. > > > > But then it would need to know which VM it was being called for, to load > the > > right JSON file. Should it just be multiple provisioner blocks, one > inside > > each config.vm block? > > > > Similarly for the pusher -- say you had a top-level config.push block > that > > knew how to parse "vagrant ssh-info" and call Capistrano -- it would > still > > need to know which app server it was being called for so that it could > call > > ssh-info for the correct app server. > > > > Any hints? Or is the right answer to just put the Provisioner and Pusher > > blocks inside the config.vm blocks and maybe wind up with a bit of > duplicate > > code? > > > > -- > > 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. > > -- > 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/MkC0k86_CCg/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.
