Do not hardcode vagrant network details

[mmlb]

Description

Allows for overriding the default vagrant/libvirt network details.

Why is this needed

Lets us use the vagrant and compose setup in a sort of hybrid mode with a real hw machine as machine1 instead of the VM.

How Has This Been Tested?

Ran vagrant up and verified defaults still work and overrides do in fact show up.

How are existing users impacted? What migration steps/scripts do we need?

A way to test with real hardware while using the vagrant setup for the services.

[nshalman]

The use of downcase seems odd when the hardcoded MAC in the Vagrantfile was using upppercase. But if it all works, then presumably the code that uses that value doesn't care.

[mmlb]

The use of downcase seems odd when the hardcoded MAC in the Vagrantfile was using upppercase. But if it all works, then presumably the code that uses that value doesn't care.

Yeah, but the hardcoded mac in ../compose/.env is lowercase so I decided to keep it that way.

[double-p]

To use a dedicated adapter (real hardware, and not everybody can tinker(!) the surrounding network to isolate VLANs etc..) one has to switch to public networking and add the hardware.
I am doing this for quite a while now:

    provisioner.vm.network "public_network", ip: PROVISIONER_IP, bridge: ENV['MYTINK_BRIDGEDEV'],

and if the real MACHINE_1 shall get network/internet access:

    provisioner.vm.provision "shell", name: "iptables", inline: <<-SCRIPT.gsub(/^ {6}/, "")
      set -x
      /usr/sbin/iptables --policy FORWARD ACCEPT
      /usr/sbin/iptables -t nat -A POSTROUTING -s #{MACHINE1_IP} -j MASQUERADE
    SCRIPT

the policy could be more strict, but "it works".

('Philipp' from chat)