Bug 1315818 switched the main networking mode from host-only to port forwarding. However: * hostonly mode is still enabled on all OSes to allow NFS to work, but we can disable it on Windows (where NFS isn't available) * the mysql port of the host was typoed as 3308 not 3306 * James was experiencing port conflicts with the wpt test runner James, for the port conflicts we can either: 1) Enable auto_correct mode (https://www.vagrantup.com/docs/networking/forwarded_ports.html) 2) Use an environment variable on the host to override the port in the Vagrantfile if set Which would you prefer?

I would prefer an environment variable and defaulting to something that doesn't conflict with widely used gecko test harnesses. See [1] for the ports that mochitest uses. wpt uses 8000 and 8443. It seems like 8080 are used but much more rarely. Something like 8088 would be totally unused, but I think that 8080 might be good enough. [1] https://dxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt

So one of the problems is that both gunicorn and runserver default to port 8000 and print the port in the console. So I'd quite like to keep the default port on the host as port 8000 to avoid confusion with contributors (many of whom won't be running gecko test suites ever, or at least not at the same time as the Vagrant VM).

Really the problem is here that a desktop app test suite has decided to use one of the most common default web dev server ports and also hasn't implemented any collision auto-detection itself.

That is a huge mischaracteristation of the problem :) The reason that testsuites typically hardcode ports is so that people can just write the actual port in the test without worrying abouts its value. web-platform-tests actually does support dynamically assigning the port, but it requires test writers to jump through hoops and therefore introduces the possibility of tests that pass or fail depending on which port is used. For that reason in production we always use hardcoded port numbers. It is inexplicable that the django runserver/gunicorn ports aren't read from the configuration file. But of course you can work around it e.g. http://stackoverflow.com/a/31244922

I agree as to the rest - my point was more if they're being hardcoded, it seems all the more important to not pick a commonly used webdev port, when any port would have been fine. (In reply to James Graham [:jgraham] from comment #4) > It is inexplicable that the django runserver/gunicorn ports aren't read from > the configuration file. But of course you can work around it e.g. > http://stackoverflow.com/a/31244922 gunicorn can be overridden using the PORT environment variable, a config file (which has to be specified using the `-c file` option) or directly on the CLI. However runserver can only be overridden each time on the CLI, which is why I posted to the Django developers group earlier today asking if they would be open to changes: https://groups.google.com/forum/#!topic/django-developers/-f_6QVC7fic

The stack overflow answer above shows a way to override the runserver port. I don't think there is an insurmountable technical issue here.

Sorry I perhaps wasn't clear before - I know that we can override using the custom management command - the newsgroup post is because it should be supported natively too, so seemed worth doing that in parallel too.

Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/d247c01782a5a0857293e6be24163d7326fc787a Bug 1320693 - Vagrant: Only enable DCHP networking on NFS platforms NFS isn't available on Windows, so the additional virtual network adapter is unnecessary.