Closed
Bug 636288
Opened 14 years ago
Closed 14 years ago
Create Cron Job for updating first reports and signaturedims
Categories
(Socorro :: General, task, P1)
Socorro
General
Tracking
(Not tracked)
RESOLVED
FIXED
1.7.7
People
(Reporter: jberkus, Assigned: rhelmer)
References
Details
Attachments
(1 file)
|
10.65 KB,
patch
|
laura
:
review+
|
Details | Diff | Splinter Review |
Please create a python wrapper and cron job for updating the first appearance of signature information, as well as updating signature_productdims.
This cron job should run on the same schedule as the TCBS cron job, i.e. once per hour, for a period 3 hours in the past.
This is the SQL you call:
SELECT update_signature_matviews( some_time, hours_back, hours_window )
example:
SELECT update_signature_matviews( '2011-02-14 16:00:00', 3, 2 );
IMPORTANT: this cron job REPLACES the signature_productdims cronjob, which currently runs once per day. Once this cron job is deployed, that one MUST be disabled.
| Assignee | ||
Updated•14 years ago
|
Target Milestone: 1.7.8 → 1.7.7
| Assignee | ||
Comment 1•14 years ago
|
||
There were some inconsistencies in the old signatureProductDims naming, just replace it all with "signatures" as the name (cron_signatures.sh, scripts/startSignatures.py, socorro/cron/signatures.py).
I don't have update_signature_matviews() in my dev DB , I've tested that it works up to the point of throwing an error about this :) Is there a bug for getting that in schema.py? I don't have it in my current bug queue.
Attachment #514863 -
Flags: review?(laura)
Updated•14 years ago
|
Attachment #514863 -
Flags: review?(laura) → review+
| Assignee | ||
Comment 2•14 years ago
|
||
Comment on attachment 514863 [details] [diff] [review]
replace old signatureProductDims
Committed revision 2961.
| Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 3•14 years ago
|
||
What's left to do here, Rob? Comment 2 has it landed, yet bug 636375 is still happening.
| Assignee | ||
Comment 4•14 years ago
|
||
(In reply to comment #3)
> What's left to do here, Rob? Comment 2 has it landed, yet bug 636375 is still
> happening.
Waiting on bug 636570 to get this running on stage (which is why I haven't marked this resolved yet).
Comment 5•14 years ago
|
||
Oh yes, sorry, it does that that dependency; my bad.
| Assignee | ||
Comment 6•14 years ago
|
||
This ran as expected, but waiting on 1.7.7 schema updates (bug 636620).
| Assignee | ||
Updated•14 years ago
|
Priority: -- → P1
| Assignee | ||
Comment 7•14 years ago
|
||
This is now running on stage, ready for QA.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 8•14 years ago
|
||
Can you lay out the steps for QA to verify. I'm not sure how to attack this one?
| Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #8)
> Can you lay out the steps for QA to verify. I'm not sure how to attack this
> one?
It's a little behind-the-scenes, I think that because bug 636375 is working, this can be inferred to be working.
Josh or Jabba, are these tables checked via any of our existing nagios scripts?
| Reporter | ||
Comment 10•14 years ago
|
||
Rob,
We just check that the cron jobs are returning success.
I'm not entirely sure how we would otherwise check the tables with nagios, since they're not current-time-based.
Updated•13 years ago
|
Component: Socorro → General
Product: Webtools → Socorro
You need to log in
before you can comment on or make changes to this bug.
Description
•