-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1654496 - Update perfherder to ingest and present test information generated by multi commit builds #6710
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6710 +/- ##
==========================================
+ Coverage 88.34% 88.42% +0.07%
==========================================
Files 280 282 +2
Lines 12802 12919 +117
==========================================
+ Hits 11310 11423 +113
- Misses 1492 1496 +4
Continue to review full report at Codecov.
|
e43cedc
to
5404488
Compare
The main implementation is pretty much done. |
590c31a
to
834ba0b
Compare
22039e1
to
243cbde
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
243cbde
to
d4a2aad
Compare
@sarah-clements as this PR implies database schema changes, I've prepared a backup plan, in case it uncovers any unknown issues. For doing the deploy, these 3 PRs should land in order: The backup plan (in case steps above have problems) is as follows:
|
This idea of toggling this on/off would only work if it's set up as environment variable, with a default value. So then Cam or I can set a value in the Heroku env settings for each deployment (ex:
Will you be testing this on prototype2 first? |
@@ -269,6 +273,15 @@ def __str__(self): | |||
return "{} {}".format(self.value, self.push_timestamp) | |||
|
|||
|
|||
class MultiCommitDatum(models.Model): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long are you planning to keep data for this table? We'll need to have expiry of old data in a separate pr.
Edit: Just realized it'll have a foreign key on perf_datum, which is already a very large table. I think we need to have another discussion about retention of perf datum since active_data is the data warehouse for data greater than 4 months.
But I'm not quite following the design of this table. It's one job with multiple commits, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long are you planning to keep data for this table? We'll need to have expiry of old data in a separate pr.
I'll keep this table for no more than 1 month, after which I'll truncate & remove it entirely. Its only purpose is to keep track of the dirty data, in case a revert is needed. With its tracking, I can easily remove the dirty data & revert the database migration.
Edit: Just realized it'll have a foreign key on perf_datum, which is already a very large table. I think we need to have another discussion about retention of perf datum since active_data is the data warehouse for data greater than 4 months.
I already filed an epic on Jira, with 4 subtasks that will make the expiry of perf data more aggressive. But we should sync about the way active_data is used for data greater than 4 months. To see if Perfherder can be adapted to use this approach also.
But I'm not quite following the design of this table. It's one job with multiple commits, right?
Yes, you got that right. It's a (perf) job which has multiple Perfherder-ingestable JSONs in it, each pertaining to a different Fenix revision. These JSONs have embedded the Fenix revision inside them + the timestamp when that revision was committed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already filed an epic on Jira, with 4 subtasks that will make the expiry of perf data more aggressive. But we should sync about the way active_data is used for data greater than 4 months. To see if Perfherder can be adapted to use this approach also.
That sounds good however, I don't have any familiarity with active data so you might want to loop in jmaher or ahal, who I believe is taking over the management of it.
Ok, I'll adapt the PRs to take this into account.
Yes, this would be an even safer approach. |
cfb7b7d
to
7e5edbc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks OK but I think it'd be good to test it on prototype before merging into master so we know how long the schema changes will take. We might want to plan for the merge to stage and production deploy to happen during a slow time since the perf datum table is rather large.
5ba1d5a
to
5dcb9c4
Compare
I just finished doing the deploy on |
I've also switched on the feature flag, to enable the new ingestion mechanism. No problems noticed. |
Well, prototype2 doesn't have that much data. That's why I think prototype would be a better deployment to test it on since it has the typical amount of perf_datum we store :) |
@sarah-clements oh, ok. I attempted a similar deploy on django.db.utils.OperationalError: (1034, "Incorrect key file for table 'performance_datum'; try to repair it") Which according to SO, was caused by the disk becoming full, as the database attempted to rebuild the new & huge table constraint. Now Django has the impression that no migration happened, when in reality we lost the original unique constraint. Update: I managed to put the database in its orignal state & deployed back the master on |
5dcb9c4
to
b9d0abc
Compare
b9d0abc
to
60c50f5
Compare
Codecov Report
@@ Coverage Diff @@
## master #6710 +/- ##
==========================================
+ Coverage 88.10% 88.18% +0.07%
==========================================
Files 282 284 +2
Lines 12878 12995 +117
==========================================
+ Hits 11346 11459 +113
- Misses 1532 1536 +4
Continue to review full report at Codecov.
|
Bug link: https://bugzilla.mozilla.org/show_bug.cgi?id=1654496