tinkerbell / playground

Example deployments of the Tinkerbell Stack for use as playground environments
Apache License 2.0
127 stars 85 forks source link

Do not hardcode vagrant network details #136

Closed mmlb closed 2 years ago

mmlb commented 2 years ago

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.

mmlb commented 2 years ago

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 commented 2 years ago

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)