maas-test fights with existing DHCP and requires internet connection to work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
maas-test |
New
|
Undecided
|
Unassigned |
Bug Description
There are two issues with maas-test needing an internet connection to work correctly:
1: maas-test needs to be the dhcp server
2: maas-test needs to connect every time it's run to download stuff
the first is sort of a "Chicken and Egg" scenario. maas-test needs to be the dhcp server, BUT if maas-test is on a network with internet access, then it is likely also on a network that has a dhcp server already running. Thus, when maas-test tries to commission, enlist and provision the SUT, there will be competing DHCP servers running, which can cause the test to fail. This happened on my home network because I have my own DHCP services running :(
To get around the dhcp issue, maas-test should not be insistent on providing DHCP services. HOWEVER, this ties into the second issue, that maas-test needs to connect to the internet every time it's run.
IF maas-test could be configured to cache it's necessary bits locally, then maas-test IS truly self-contained and won't need the internet connection, thus a server can be directly plugged in to the maas-test machine on a completely segregated physical LAN.
The scenario I envision being used the most is this:
Tester is working to test several $OEM servers at the OEM's test lab. The Test lab is NOT permitted to have access to the internet at any time, and it is also forbidden to have a system connected to the test lab that is simultaneously connected to the internet. This is not uncommon, as OEMs require this sort of arrangement to protect systems that are currently being developed from remote access and discovery by third parties, and to protect they're typically Windows based workstations from being infected by the virus du jour.
So to test the system, the tester first plugs in his test machine (a laptop) and runs something like 'maas-test --prepare' which connects to the internet and downloads all the necessary packages required to test and caches them locally. THEN the user carries his laptop into the test lab, plugs it into a switch that is ONLY connected to the ethernet and management ports of the SUT and runs 'maas-test <options> eth0' to test that laptop using the Ubuntu version that is required (saucy, Trusty, etc). Perhaps an option used would be something like this: 'maas-test --release trusty <bmc options> eth0'
As it stands, because of the dhcp requirement, I am unable to successfully run maas-test on my home LAN because maas-test expects my server to have one IP address, when it's getting a completely different one from my personal DHCP service. And, because of the internet requirement, I can't disconnect from a DHCP service and run maas-test either. THe only real option then is to introduce a second machine to act as a secondary gateway, but that simply adds unnecessary overhead to the test process.
Also, I think the idea originally is that maas-test would be run on a machine with two Ethernet ports, but this is not, IMO, a realistic expectation. I think its far more likely that the typical use case will be to want to run maas-test from a laptop that can be carried from machine to machine to machine, making maas-test far more useful as I, a Canonical employee, can carry my laptop to OEM labs around the world to use maas-test, or to trade shows to test machines as a demonstration, or to provide demos to other groups.
Additionally, currently I can run maas-test at home on a laptop with the wifi adapter talking to the internet and the ethernet adapter plugged into a segregated test lan with my SUT.
BUT, this most likely will not work in an OEM test lab/Data Center situation where wifi will be either non-existent or unreliable, and that's not accounting for the OEM not allowing machines to straddle the line between public and private networks.