On 8 March 2016 at 15:13, Eric Helms <ehelms(a)redhat.com&gt; wrote: You can setup an unmanaged network, and then use brctl after 'lago init' to attach a public interface to the bridge it creates. But if you need that you are not using Lago the way it was meant to be used, network isolation was baked in on purpose. Why do you need this? -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

On 8 March 2016 at 18:25, Eric Helms <ehelms(a)redhat.com&gt; wrote: Faced with the same dilemma when running oVirt on Lago on my MiniDell, I've simply setup Apache on it to proxy HTTP traffic into the VM network. With a browser proxy plugin such as foxy proxy configured to make the browser also resolve DNS for domains with certain suffixes over the proxy, I've got a pretty seamless user experience without giving up on the environment isolation. If you want this to be self-contained in a script you give developers, you can perhaps use the Ruby or Python built-in HTTP servers to do the proxying. -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

On Tue, Mar 8, 2016 at 11:57 AM, David Caro <dcaro(a)redhat.com&gt; wrote: 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. Eric

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. 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(a)redhat.com RHEV-CI Team