Closed Bug 401816 Opened 17 years ago Closed 17 years ago

Deploy reporter service update

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: raccettura, Assigned: justdave)

References

(
URL
)

Details

Attachments

(1 file)

Patch
1.98 KB, patch
Details | Diff | Splinter Review 
Just landed bug 389128.  Need to get this live sooner than later.  Minefield will not work with it until that patch is live.

reporter-stage.mozilla.org is updated for testing (anyone who needs a PW can contact me for that).  My tests with Firefox 2, and Minefield (patched w/ 389131) were all successful.

I'd prefer this be done when I'm around, just in case... but it applied cleanly to reporter-stage so I'm pretty confident in this.
URL: http://reporter.mozilla.org
Severity: normal → major
Component: Server Operations: Web Content Push → Server Operations
Flags: needs-downtime+
Does Thursday night this week work for you? (7p-11p range Pacific time usually, but we're flexible)
Not really, since I'm up 5:00 EST Friday morning.  Friday evening does work.

FWIW provided we have a backup, no true "downtime" really needed, patch should apply cleanly, no db changes, etc. etc.  It's just a new interface for the client to access the server.
If we can get everybody up and online Thurs morning I'm okay with doing the update, but would like at least a few others test this with Fx 2.  Worst case, I can be around Thurs during the window to help test and Robert can help with a checklist -- sound like a good compromise?
Robert could you help organize testing on stage?  Want to make sure all is good for fx2/fx3.
Tomcat said he can help out with testing.  Thanks Carsten.
Anyone testing can email me for directions on how to access stage.
here are my first test results:

i tried the Firefox 2.0.0.9 Firefox Build and the 1.8 Branch Tinderbox Build and both were successful to submit reports and i was also able to see my report on reporter.mozilla.org.

With the Tinderbox Build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103114 Minefield/3.0a9pre i have a problem.

I log into reporter-stage.m.o with the password i got and then i try to report a site as broken (in this case i used the stage site). After some seconds i got the information that a problem occurred and my report was successful submitted. As "details" i got - cannot connect to server. 

The difference to a unpatched trunk was that reporter did not try forever to send the report and that i got with the patched build very shortly a Error Message.

BTW, i noticed that on reporter.mozilla.org the querys don`t work when i use the "Product" Option, like to search for Firefox 2.0.0.9 Reports. Is this a known bug ? 
update from the testing:

Mac/Linux/Windows are fine with Firefox 2.0.0.9 RC1 and Nightly 1.8 Build, i can submit and see the report.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103114 Minefield/3.0a9pre -> is fine

on:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre)
Gecko/2007103117 Minefield/3.0a9pre and 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007103116 Minefield/3.0a9pre i get as Error: Invalid SysID and the sending of the report fail.

i will try later with Trunk Nightly Build to test if this only a problem with this tinderbox Build ID's
Tested again with new profiles on mac and linux and i`m now able to send reports on all platforms !

with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103114
Minefield/3.0a9pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110106
Minefield/3.0a9pre
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre)
Gecko/2007110105 Minefield/3.0a9pre
We're ready to go live with this -- can someone update this during tonight's window?  I will be online if there are any issues.
I'll be online for the next half hour or so.  And again tomorrow morning.
OK, on the premise that an announced downtime window is pointless because the majority of the people impacted are end-users who will never see any notice we post anyway, let's go ahead and roll with this.  As long as there's people around to hack on it until it works if it's broken, I'm game.  What's the upgrade procedure?
Assignee: server-ops → justdave
This was done.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Thanks Dave.
verified fixed -> Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007110103 Minefield/3.0a9pre is now able to send reports to reporter.mozilla.org

thanks guys ! 

-> verified
Status: RESOLVED → VERIFIED
2.0 is busted... I've got a patch
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached patch Patch — — Splinter Review 
Fixes 2.0 bustage.

Considering things are problematic right now, and degree of changes (minor) I'll self review, so r=me.

I don't have cvs local right now (did a diff on willow), so could use a checkin.
I checked this in -- why didn't we catch this during testing, so we know what to look for next time?
FWIW both Carsten and myself submitted reports on 2.x and trunk and got successes, so this is a bit confusing.
Dave updated this in prod and it looks better.  Our tests before probably did not spot the missing RMO id for 2.x clients.  I filed bug 402236 so we can have some automated testing to run to verify code changes don't introduce regressions.  That should help down the road.

Robert and I both verified working on 2.x and trunk.  Thanks everyone. :)
Indeed thanks.

I'll be doing some extra testing later tonight and tomorrow to see if there's any other issues.
Based on comment 20 I'm assuming this is fixed now.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: