We need a vm to run a webserver for the firebug unit tests. This server will do two things: * hg pull -u from the hg.mozilla.org/automation firebug repo (this pulls down the firebug tests * Serve these tests as a webserver to the test slaves inside the build network. * It will need to have a well-known name so that the slaves can reliably reference it, i.e. firebug-test-server.build.mozilla.org or some such. Or even just an assigned IP that won't change. It's fine to co-host this on some other webserver if there is another webserver with spare cycles in the build network. I'll leave that up to you guys to decide.

Why can't the firebug tests host themselves like mochitest, reftest, etc?

(In reply to comment #1) > Why can't the firebug tests host themselves like mochitest, reftest, etc? We tried, and the short answer is it doesn't work. They need to be served externally otherwise they fail.

If we do go this route scaling is going to be an issue. We'll have 10s to possibly 100s of machines hitting one test server initially. And in the future, we'll have to manage the complexity of having a test server per datacenter or have the tests served over a long distance. All of these complexities will increase the chance for network-related orangeness.

I understand where you're coming from, but I'm not exactly sure how to solve it without this server. We have several moving parts to this problem, let me go through them. 1. The firebug tests don't run properly with a local httpd.js webserver. 2. We probably don't want to install apache on all the slaves to serve firebug tests (if this is not true, then maybe we can revisit?) 3. We don't want to change the tests significantly to run in "our system" because we want to maintain parity with the tests that developers run on getfirebug.com. That said, we could certainly work with the Firebug team and coordinate upstream changes like that. We'd just want to coordinate with them and get their buy in that we're not eviscerating their test by making these changes. 4. The firebug tests come from firebug's repo, and new tests as well as test fixes come from firebug's repo. 5. The firebug extension itself is not built in m-c, it is built in firebug's system and provided in their repo. Beyond serving tests, this server is our answer to enable the slaves to be able to get the firebug tests as well. We will maintain a server (separate from the one this bug is filed for) which will pull the svn firebug repo and push it to an hg repo once a day. This server will update from that hg repo and serve tests for the slaves. This way none of the slaves will ever be reaching out to getfirebug.com in order to obtain the latest code for firebug and its tests. So while we could possibly solve the local vs remote scaling issue, we're still going to need this server to mirror the firebug tests/extensions into the build network in such a way that nothing in the build network will hit an external site. I'm open to suggestions if you have a better way.

Do we have a security concern because we would be running non-moz test code inside our firewall? I am also worried that requiring a web server now will make us have to have a small cluster of web servers for each of our colo's or else IT may not like the increased traffic if we use a centralized one. If we start with only one, we would have to plan on growing it to multiple-per-colo

We have Apache on the slaves for running talos tests, would that be suitable ? The firebug tests could be handled like talos.zip is, downloaded from build.m.o, much as I dislike the external code.

Using apache would work if the content being served doesn't require anything special as far as apache modules are required (or if modules are required then we need to verify that they can run on the os's we are using.) Does the content require anything like .htaccess rewrites or cgi? or is it just static content? do you have sample apache config for this?

(In reply to comment #7) > Does the content require anything like .htaccess rewrites or cgi? or is it > just static content? do you have sample apache config for this? Yes, unfortunately there were a handful of tests (maybe 10-20 iirc) that require PHP. I also think you need to have mod_rewrite enabled. Honza, can you confirm if this information is correct or if there are any other dependencies?

Yes, some tests (there is 28 *.php files) require PHP and some tests also use .htaccess Honza

That pushes us strongly in the direction of using the existing Apache on the test machines to run the tests from.

zandr: I think we need to build a VM on the Build ESX host and give them access to build VPN.

Actually, I'm going to pull this into RelEng until we figure out what we're doing here. We don't have consensus on using an external webhost yet.

Damn, I mid-aired y'all and lost my comment. Yeah, I think we might be able to get by without the VM. I'd also prefer to have the tests running in the local apache webserver if possible. In order to determine what (if anything) needs to be installed/configured in that local apache installation, can we get Andrew a loaner slave so that he can experiment with getting the firebug tests to run locally by hand? This way he can create a concise set of things we'll need to change (or not) on the buildslaves so that we can impart this capability to them. I think he'd prefer a linux slave as he's more of a linux guy, but I can let him comment on that. We still have the issue that we need a way to get the Firebug tests and test runner onto the slaves. I think we can do that by simply downloading the archive of the mirrored firebug repo from hg. (We will be mirroring the official firebug SVN repo into hg at http://hg.mozilla.org/automation/firebug/). That's how we get the tests and test runner for jetpack, so I think that's entirely do-able from the buildslaves.

> can we get Andrew a loaner slave so that he can experiment > with getting the firebug tests to run locally by hand? This way he can create > a concise set of things we'll need to change (or not) on the buildslaves so > that we can impart this capability to them. I think he'd prefer a linux slave > as he's more of a linux guy, but I can let him comment on that. I'd prefer linux, but we need to figure this out on all platforms anyway, so whatever is available would work.

If you're looking for something that's like a test machine you don't want a Linux VM, you'll want temporary access to one of the staging machines. We don't have any test machines that are virtualized.

(In reply to comment #15) > If you're looking for something that's like a test machine you don't want a > Linux VM, you'll want temporary access to one of the staging machines. We don't > have any test machines that are virtualized. yeah, that's what I was talking about in lucky comment 13. If we get andrew one of the actual slave staging/real talos rev3 slaves, he can look over the apache configs and figure out if we need to change anything in order to run firebug locally. I'm not talking about a vm at all, sorry for the confusion. We could use our tools-staging slaves, but our tools-staging slaves are not managed by puppet/opsi and with Alice out, they could be out of sync from the real environment in the official slave pool.

RelEng coordinates the loaning of these slaves, so I'm going to pull this back in and assign it to the slavedduty person (Dustin).

Albert: once 636273 is done, you'll want to use e.g., ssh -L 5900:talos-r3-fed64-002.build.mozilla.org:5900 build-vpn.mozilla.com to connect. Ping me or anyone in releng via IRC for the password.

Sorry, I got pretty sick last week and didn't find the time to do this then. So the only two things needed are PHP and mod_rewrite as mentioned above. In terms of configuration to httpd.conf I did very little: - LoadModule libphp5.so ... - AddType text/html php - AllowOverride None -> AllowOverride All However, the only way I know how to configure apache and php is to make php from source. I found I needed a couple of packages to set it up. - gcc (maybe there was already a compiler somewhere on there?) - libxml2-devel (to configure php) - httpd-devel (to get the aspx tool) I don't know if I configured php the easiest way or not but it seems like as long as mod_php and mod_rewrite are working the tests are good to go.

Does the slaveduty whiteboard flag mean that you guys are going to fix the slaves to enable them to run these tests locally? If so, we should probably morph the title of this bug to reflect reality.

No, it means slaveduty should be aware that this slave was loaned. I think everyone's focused on RC1 at the moment, hence no answer yet on actually fixing things to run the tests.

In the future, let's not morph bugs this way. AFAICT, this bug was strictly about the loaner machine for autotools. There are specific actions that need to be taken for loaning out a machine and then bringing it back into the build network, including some follow-up work from IT which is tracked in an IT bug. These actions are separate and distinct from the actions involved in setting up a new webserver (if required) and/or adding new testsuites for firebug if the prereqs are now understood. Can we get new bugs filed for the follow-up actions? Dustin: this includes the requisite re-imaging bug for the returned slave. Not trying to be a stick-in-the-mud here, but if bugs change meaning/intent mid-stream, it makes it near-impossible to keep track of things.

I think coop had this backward - this was not the loaning bug, but rather was the bug about firebug tests. ahal, if you're done with the slave, let me know and I'll repatriate it. Otherwise, let me know and I'll open a new bug to track the loan. Either way is fine, just let me know.

Dustin, I'm finished.. you can wipe it.

Was this resolved fixed because I'm finished with the loaner slave or because the local apache configurations have all been updated with PHP and mod_rewrite? My instinct says the former. In that case I think this needs to be re-opened.

Sorry, you're right.

Who should I ping to see if I can get this moving?

What needs to happen here now? What needs to be updated with PHP and mod_rewrite? All our test boxes?

(In reply to Lukas Blakk [:lsblakk] from comment #28) > What needs to happen here now? What needs to be updated with PHP and > mod_rewrite? All our test boxes? Yes, all of them, if we're going to finish this out. See the go/no-go thread on bug 685903.

This is no longer a goal.