Hey there Benny, Thanks for taking a look at the action triggers! I'll respond inline
On Thu, May 16, 2019 at 1:46 AM Benjamin Riefenstahl <[email protected]> wrote: > Hi everybody, > > I'm new to this list, so please forgive me if this has been discussed > before, or if the solution is too obvious ;-) > > We have a Vagrantfile that runs fine with 1.9.4 but has a problem with > 2.2.4. We use the vagrant-triggers plugin and I am trying to make it > work with core triggers. > > The Vagrantfile creates a development test system that consists of a > number of Debian VMs. For networking we use host-only private network > to isolate our testing from the rest of the world. Initially the VMs > need to be provisioned by installing packages from a Debian repo. To > connect to the repo we use a company internal HTTP proxy and port > forwarding from the VMs to the proxy on the host. > > So to quote some code, we are doing this: > > config.vm.define opts[:name] do |host| > # ... > host.vm.provision :trigger, run: "always" do |trigger| > trigger.fire do > run "vagrant ssh #{opts[:name]} -- -f -R 10000:proxy:8080 -N" > end > end > > With 2.2.4, a direct translation of this would be something like > > host.trigger.before :all do |trigger| > trigger.run = {inline: "vagrant ssh #{opts[:name]} -- -f -R > 10000:proxy:8080 -N"} > end > Ah ok, so actually what you have written here is a trigger that will run before a given guest runs any command, which I don't think is exactly the same. You are correct in thinking that Vagrant::Action::Builtin::Provision would be the right action to run before the provision step. Unfortunately that action does not work exactly how you would expect it to work. It actually runs very early in the vagrant life cycle and returns early before actually running any provision steps. So even if you get the trigger working, it would run before you expected it to. We have plans of adding a basic Provision action "stub" so that you can do exactly what you are wishing to here, but we haven't got there yet. That being said! For now you should be ok attaching your trigger to another action, perhaps? > > But that does not work, because I can not execute "vagrant ssh" before > "vagrant up". "before :provision" does not work either, when I execute > "vagrant up" before the machine even exists, because the trigger is not > called for the provisioning step implied here by "vagrant up". > > The main things I tried: > > * ssh.extra_args, ssh.config - These do not work, because for > provisioning the standard SSH tool is not used, but a pure-Ruby > implementation of SSH that does not use these parameters. The Ruby > implementation supports remote forwards, but as it seems only via an > extra API. BTW: You want to mention in the documentation which of > these config parameters apply to provisioning, if any. > > * trigger.before :"Vagrant::Action::Builtin::Provision", type: :action - > I enabled VAGRANT_EXPERIMENTAL=1 but this trigger does not seem to be > called. These new triggers are not yet fully documented it seems, so > I searched the code for a hook but could not find anything that works. > Apologies for this. The feature isn't as fully functional as I had hoped after implementing it, which is why it's mostly guarded behind the experimental flag at the moment :) We have some provosioner enhancements coming *soon* and will include some stuff that should make this a little nicer to work with. That should include making these docs better, and hopefully removing the experimental guard. > > I have some work-arounds, but than it seems easier for now to just stick > with the old version of Vagrant. > > Regards and TIA for any hint, > Benny Riefenstahl > > -- > mecom Medien-Communikations-Gesellschaft mbH > > Mittelweg 143, D 20148 Hamburg > > Tel: +49 40 411332 801 > > Fax: +49 40 451962 > > http://www.mecom.de > > Registergericht Hamburg, HRB 43177 > > Geschäftsführung: Barbara Bliefert, Norbert Schmidt-Banasch > > -- > This mailing list is governed under the HashiCorp Community Guidelines - > https://www.hashicorp.com/community-guidelines.html. Behavior in > violation of those guidelines may result in your removal from this mailing > list. > > GitHub Issues: https://github.com/mitchellh/vagrant/issues > IRC: #vagrant on Freenode > --- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/vagrant-up/86ftpe9475.fsf%40riefenstahl3.mecom.de > . > For more options, visit https://groups.google.com/d/optout. > -- Brian Cain -- This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list. GitHub Issues: https://github.com/mitchellh/vagrant/issues IRC: #vagrant on Freenode --- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/CADHESCWuYxSEi6Fyx4FVJNZ-Xx5UB3agYeokr71j2z61OOWfug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
