Create Cron Job for updating first reports and signaturedims

RESOLVED FIXED in 1.7.7

Status

Socorro
General
P1
normal
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: jberkus, Assigned: rhelmer)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 629054
(Assignee)

Updated

7 years ago
Target Milestone: 1.7.8 → 1.7.7
(Assignee)

Comment 1

7 years ago
Created attachment 514863 [details] [diff] [review]
replace old signatureProductDims

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

7 years ago
Attachment #514863 - Flags: review?(laura) → review+
(Assignee)

Comment 2

7 years ago
Comment on attachment 514863 [details] [diff] [review]
replace old signatureProductDims

Committed revision 2961.
(Assignee)

Updated

7 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

7 years ago
Depends on: 636570
OS: Mac OS X → All
Hardware: x86 → All
What's left to do here, Rob?  Comment 2 has it landed, yet bug 636375 is still happening.
(Assignee)

Comment 4

7 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).
Oh yes, sorry, it does that that dependency; my bad.
(Assignee)

Updated

7 years ago
Depends on: 636620
(Assignee)

Comment 6

7 years ago
This ran as expected, but waiting on 1.7.7 schema updates (bug 636620).
(Assignee)

Updated

7 years ago
Priority: -- → P1
(Assignee)

Comment 7

7 years ago
This is now running on stage, ready for QA.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Can you lay out the steps for QA to verify. I'm not sure how to attack this one?
(Assignee)

Comment 9

7 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

7 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.
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.