Add .htaccess file to bouncer for euballot rewrite



5 years ago
a year ago


(Reporter: jd, Assigned: laura)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



5 years ago

We would like to have an .htaccess file added to bouncer/tuxedo/download.m.o for the euballot rewrite. This is basically so we (webops) can get out of the way of the release cycle and to remove the dependance on us like in bug 860878. Currently the rewrite looks like:

    RewriteCond %{QUERY_STRING} ^(.*)product=firefox-latest-euballot(.*)$
    RewriteRule /(.*)$$1?%1product=firefox-20.0.1-euballot%2 [R=302,L]

and we are hoping it will be a simple matter to pop that into an .htaccess file and then we can pull it from the apache/puppet config train.

Please let me know if I can do anything to help, feel free to ping me on IRC for testing in dev or whatnot.


Comment 1

5 years ago
Any idea about this? It is the correct place to file? General unknown beyond my meager ability to comprehend? Lack of interest? Anything I can take back to my boss and the PTB? It is tied to a quarter goal FYI.

My eternal gratitude and an offering of a feral pig to the god of your choice for resolution.
[drive by comment from RelEng, who are currently filing the bugs like bug 860878] 

So who would edit the .htaccess and how ? Still puppet controlled so falls on SRE's instead ?

The general fix would be something like bug 801208 or bug 863381.

Comment 3

5 years ago
For similar situations in the past the developers have put the .htaccess in whatever version control system they use for the site code. This enables them to update and then push via chief or whatever their normal push mechanism is.

I am not sure who maintains the code or who is initiating the request for the change we are concerned with here. The idea is to remove webops as a roadblock / slow point for this part of the release cycle. If this is not something appropriate for the developers to handle then we should determine who the initiating (AKA responsible) party is and then determine how we can empower them to make this small change. This is the last thing that my team does during the release cycle IIRC and so it is the last part of a larger goal of getting us out of the way (related to bug 842578 and bug 827475).

If one of the bugs you mentioned will suffice to remove this dependency on us that that is a workable solution as well. So long as the end goal of us not delaying releases is satisfied than I will be one happy camper.

Please let me know your thoughts and thanks for the response.

Comment 4

5 years ago
This is on my team: Brandon was going to do it but he's on PTO.

I'll try and get a patch up tomorrow.
Assignee: nobody → laura
Laura, any idea what the process will be after adding the .htaccess ? Will WebDev be on the hook to patch the file and deploy via Chief ? Not sure who has access to the github repo or Chief for bouncer.

Another approach might be do something very similar to bug 398366, except for testing on product_name being 'firefox-latest-euballot', and the redirect_url would have a product like 'firefox-' . $latest . '-euballot'. Then no action would required other than updating product details, and people are already doing that.

Comment 6

5 years ago
Bouncer is deployed by webops, once we generate a patch.  One thing that is handy to know is that we actually have a set of tests that check all the redirects work (and that we don't regress any), because there are quite a lot of them. This should be fairly simple so I don't anticipate problems.

Comment 7

5 years ago
Let's think about this a bit more.

Merely moving the redirect to a .htaccess file doesn't solve the point. The point is we want to get webops out of the Firefox release process, and let releng handle this change on their own. If we still have to do a deploy, then we're no closer to the goal.... further, in fact, if webdev now has to maintain the redirect, because now 3 teams would be involved.

Moving this into a .htaccess *might* solve the goal, if that .htaccess is easily editable and deployable by releng. How can we do that?

I do like Nick's alternative suggestion... we already pull in product-details for the firefox-latest product, so this probably wouldn't add any new dependencies. There's a cron that updates product-details hourly.
Created attachment 761252 [details] [diff] [review]
Modify existing 'alias' handling

This is a quick attempt to modify the firefox-latest handling we already have, as described in comment #5.

Comment 9

5 years ago
This lgtm, but I don't have a bouncer install atm - asked pmac to actually test it.
(In reply to Nick Thomas [:nthomas] from comment #8)

Seems like the pattern of "firefox-latest-XXX" will be common. If that's true we could easily do a regex match instead of looking for "firefox-latest" or "firefox-latest-eubalot". Something like /^firefox-latest(-\w+)?/. Then request `"firefox-" + $latest_version + $1`. Seems like that would be a bit more future-proof.

Also, does this mean that "firefox-latest" is available for more than just Windows builds, or is that another thing all together?
Taking those in reverse order ....

At the moment firefox-latest and Firefox-21.0-EUballot products only have locations configured for Windows. The EUballot is windows only by design (bad MS, go sit in the corner!); firefox-latest is used by the release stub installer, which is also windows only. One thing that might change that is that we get requests from sysadmins to provide a version-independent url to get the current release, so firefox-latest might include the other OS in the future.

AFAIK there are no plans to have other firefox-latest-XXX products for a release version. Beta/aurora/nightly, which are firefox-XXX-latest, would need to look up other versions in the json, so the patch would a bit more than you sketch. The EUBallot case is only used for release builds.

From a RelEng point of view, it would be great if we didn't have to update any -stub or -latest products when version bumps happen though. As I mentioned in comment #2 there are other bugs on file for that, but are larger in scope so perhaps they don't fit this quarter.
(In reply to Laura Thomson :laura from comment #9)

If my setup is right, this appears to work the way it's supposed to. The code looks right to me as well.

Comment 13

5 years ago

Any update on this? Need anything from webops to keep this moving forward?


Comment 14

5 years ago
Any update to this? Anything I can do to help? Thanks :)
Laura is on vacation but I'll take a look at this now.

Paul, has this been merged in Master?
Flags: needinfo?(pmac)
(In reply to Brandon Savage [:brandon] from comment #15)
Not to my knowledge. I just reviewed the change.
Flags: needinfo?(pmac)

Comment 17

4 years ago
Hello my friends. Just curious if there is any movement on this front?

Bug 863381 added support in bouncer for this sort of thing.
Depends on: 916181

Comment 19

a year ago
I am guessing that this is no longer an issue. As it stands I am no longer in WebOps and don't have access to address it. If this is still an issue, feel free to reopen and ping WebOps about it.

Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.