-
Notifications
You must be signed in to change notification settings - Fork 31
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
Fix summariser time CpuCount warnings for cloud accounting #156
Conversation
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.
Looks good. Just a couple of things in the comments.
|
||
-- This section will: | ||
-- - Change records with a NULL CpuCount so that they have a CpuCount of 0, | ||
-- to prevent summariser time problems. |
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.
Little ambiguous. You mean problems at summarising time, 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.
Yes, change made
test/test_mysql.py
Outdated
@@ -290,5 +295,24 @@ def test_last_update(self): | |||
CloudType: Cloud Technology 2 | |||
''' | |||
|
|||
# A Cloud V0.4 Record, but missing a lot of fields. | |||
# We need to check we can this record as we receive |
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.
Missing "load"?
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.
Yes, change made
Changes made |
- the test captures what happens as of 1.6.1 and helps convince us we aren't breaking anything when making any future chnages to default CloudRecord values.
- Helps convince us we aren't breaking anything when making any future changes to default CloudRecord values
- when it is ommited, NULL is written as the CpuCount in the CloudRecord table, which causes problems at summariser time as NULL CpuCounts aren't allowed in the CloudSummaries table
- Cleans up any existing cloud data with a NULL CpuCount, which causes warnings when we try and insert cloud summarises with NULL CpuCounts into the cloud summary table
dd4aaef
to
c4d8da0
Compare
I've split the comment fix commit, squashed each bit into the relevant commit, and rebased. |
The warnings are caused by CloudRecords with a NULL CpuCount forming CloudSummaries with a NULL CpuCount, which causes the warning because CpuCount is now part of the CloudSummaries primary key (following a bug fix in 1.6.1).
I have made a change to
cloud.py
to prevent new CloudRecords being loaded with a NULL CpuCount, opting for zero as the replacement, so CloudRecords without a CpuCount are as separate as possible from those that do.I also added test cases to try and highlight what was changing and to show that everything still seems to work.
Manual Testing
Tested by loading the below message repeatedly into a Cloud database (10.1.20-MariaDB) on a SL7 VM
under 1.6.1, when loading that message we pass NULL to CpuCount, rather than relying on implicit type correction that's not supported out of the box in newer mysql/mariadb. Woo!
This causes the summariser warnings, because CpuCount is in the primary key and hence NOT NULL in the CloudSummaries table.
We get away with it because of the implict type correction of NULL to 0 that's not supported out of the box in newer mysql/mariadb. Boo!
To fix existing data, applying the update script
and no stale summaries :)
The changes to the
cloud.py
mean newly loaded records without a CpuCount get a CpuCount of 0.