Merge ~raharper/cloud-init:logging-gmtime into cloud-init:master
| Status: | Merged |
|---|---|
| Approved by: | Scott Moser on 2017-08-25 |
| Approved revision: | 7c790cbcc882dc164a8fbfdb0b352c18b74614b3 |
| Merged at revision: | 556a0220734097aa4e9fbfd93c8f263684232b3b |
| Proposed branch: | ~raharper/cloud-init:logging-gmtime |
| Merge into: | cloud-init:master |
| Diff against target: |
87 lines (+63/-0) 2 files modified
cloudinit/log.py (+5/-0) tests/unittests/test_log.py (+58/-0) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Scott Moser | Approve on 2017-08-23 | ||
| Server Team CI bot | continuous-integration | Approve on 2017-08-23 | |
| Chad Smith | 2017-08-16 | Approve on 2017-08-16 | |
|
Review via email:
|
|||
Description of the Change
Configure logging module to always use UTC time.
Currently the python logging module will default to a local time which may contain an TZ offset in the values it produces, but the logged time format
does not contain the offset. Switching to UTC time for logging produces
consistent values in the cloud-init.log file and avoids issues when the timezone is changed during boot.
LP: #1713158
| Chad Smith (chad.smith) wrote : | # |
Looks good, I'm going to keep beating the "unit test coverage" drum on this. Can we add an initial unit test for log in
cloudinit/
Maybe this nit isn't worth it though, your call.
I tested on systems w/ localtime set mountain and things look good.
| Chad Smith (chad.smith) wrote : | # |
minor flake8 fix as you'll see from CI
| Scott Moser (smoser) wrote : | # |
lets add a unit test and then i approve.
just do a log, and verify the format comes out correctly.
PASSED: Continuous integration, rev:89508f822bf
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
I think your test case has fence post errors at the end of a minute. I, if we read it now() in the 59th second and the log message happens in the next second the test will fail. Right?
One way to combat this would be to get a before timestamp and an after timestamp. Then parse the log message time stamp and assert that before >= log >= after.
| Ryan Harper (raharper) wrote : | # |
On Tue, Aug 22, 2017 at 10:17 PM, Scott Moser <email address hidden> wrote:
> I think your test case has fence post errors at the end of a minute. I, if
> we read it now() in the 59th second and the log message happens in the next
> second the test will fail. Right?
>
> One way to combat this would be to get a before timestamp and an after
> timestamp. Then parse the log message time stamp and assert that before >=
> log >= after.
>
Good suggestion. I'll fix
>
> --
> https:/
> cloud-init/
> You are the owner of ~raharper/
>
PASSED: Continuous integration, rev:7c790cbcc88
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
As long as AssertGreater and friends work in a python2.6 (tools/run-centos 6) i approve.
just make sure of that and then merge.
thanks!
(i do not know that they don't, i just hadn't used these before).


FAILED: Continuous integration, rev:e8c2885ff24 e74af027dc297be d85c1d744c039c /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 149/
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild: /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 149/rebuild
https:/