Can you help me visualize what this would look like from a code or user perspective? Right now I have it reduced to "run this script" and environment gets setup and installation steps occur. Ideally, that same script would setup or configure whatever is needed so a developer just hits the IP in their browser and is off and running.
If you bridge the VMs directly to the external network, you would need to to apply external network IP configuration for the VMs, which may or may not be simple depending on how the external network is configured. (If this is what vagrant does, then the fact that it worked for many developers so far is just sheer luck) Any names or IPs the external network would assign to the VMs can be completely random, the external DHCP may also just refuse to assign anything, the developer may even run his setup on a network without DHCP, that would force him to somehow manually assign an external IP to the VM running Satellite. Since Satellite is running on a VM it knows nothing about the hostname and IP of the underlying host, if we want the developer to eventually enter the host address in his browser, we could perhaps, use NAT or HTTP reverse proxy to expose ports from the VM on the host, but fully-qualified URLs in links or redirects sent from the app will not function properly since they will point to the VM hostname which is unknown on the external network. You can vision the situation like this - the dev laptop is attached to the "internet" while the Lago network is a closed separate network sitting behind a firewall. Host names and addresses on the Lago network are not and cannot be exposed to "the internet". To allow the dev laptop to work against the VMs you need something that essentially behaves like a VPN, so its hard to avoid any setup on the dev laptop.
For the ports, just adding an option to the nets specifying with ports to forward to which ips/vms
For the ssh tunnel, you have to start it from your laptop to the machine that is running lago, something like:
ssh -D 8888 -Nf lago_machine # the -N is for not running any command, -f is to go to background
That will start a socks proxy at 127.0.0.1:8888 (in your laptop) that you can setup in your browser as proxy, and will forward any traffic through it, so pointing your browser to the internal vm ip/name should work.
This solution may work but I think there will be an issue with name resolution because the SSHD running on the host AFAIK does not know to resolve names against the Lago internal DNS. Also I'm not sure browsers know how to resolve hostnames via socks proxies in the same manner they know to resolve via HTTP froward proxies. I now remembr that the way it worked for me was that I had configure MDNS on all the VMs and the host so that multicast name resolution was working through the Lago bridges, this solution is not applicable to the general case. What we need is a proxy process, running on the host, that is attached to the external network on one end and to the Lago internal one on the other, and is configured to resolve names against the internal Lago DNS. There are a few challenges here especially if you don't want to modify the outside-visible configuration of the host (for example '/ets/resolv.conf' on the host may be DHCP-managed so you cannot change it). With some scripting, the end-user experience could come down to: 1. Run our script on the beefy host 2. Go to we page on the beefy host that would setup the VPM/proxy seeting for you. I think there may be an interesting Lago feature we could have here - Have a 'lago proxy' or 'lago vpn' command to expose a Lago network via a proxy or a vpn. -- Barak Korren bkorren@redhat.com RHEV-CI Team