Project

General

Profile

Bug #10316

Some Foreman reports show incorrect time as GMT

Added by Bryan Kearney over 5 years ago. Updated over 5 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1184591
Description of problem:
Some reports in Satellite 6, such the runtime and resources reports under a host definition under Hosts -> All Hosts, show the time incorrectly as GMT. How do we configure this to show the correct current timezone?

Version-Release number of selected component (if applicable):

Installed Packages

candlepin-0.9.23.1-1.el7.noarch
candlepin-common-1.0.1-1.el7.noarch
candlepin-guice-3.0-2_redhat_1.el7.noarch
candlepin-scl-1-5.el7.noarch
candlepin-scl-quartz-2.1.5-6.el7.noarch
candlepin-scl-rhino-1.7R3-3.el7.noarch
candlepin-scl-runtime-1-5.el7.noarch
candlepin-selinux-0.9.23.1-1.el7.noarch
candlepin-tomcat-0.9.23.1-1.el7.noarch
elasticsearch-0.90.10-6.el7sat.noarch
katello-1.5.0-30.el7sat.noarch
katello-certs-tools-1.5.6-1.el7sat.noarch
katello-default-ca-1.0-1.noarch
katello-installer-0.0.64-1.el7sat.noarch
katello-server-ca-1.0-1.noarch
pulp-admin-client-2.4.3-1.el7sat.noarch
pulp-katello-0.3-4.el7sat.noarch
pulp-nodes-common-2.4.3-0.1.beta.el7sat.noarch
pulp-nodes-parent-2.4.3-0.1.beta.el7sat.noarch
pulp-puppet-plugins-2.4.3-1.el7sat.noarch
pulp-puppet-tools-2.4.3-1.el7sat.noarch
pulp-rpm-plugins-2.4.3-1.el7sat.noarch
pulp-selinux-2.4.3-1.el7sat.noarch
pulp-server-2.4.3-1.el7sat.noarch
python-gofer-qpid-1.3.0-1.el7sat.noarch
python-isodate-0.5.0-1.pulp.el7sat.noarch
python-kombu-3.0.15-12.pulp.el7sat.noarch
python-pulp-bindings-2.4.3-1.el7sat.noarch
python-pulp-client-lib-2.4.3-1.el7sat.noarch
python-pulp-common-2.4.3-1.el7sat.noarch
python-pulp-puppet-common-2.4.3-1.el7sat.noarch
python-pulp-rpm-common-2.4.3-1.el7sat.noarch
python-qpid-0.22-15.el7.noarch
python-qpid-qmf-0.22-37.el7.x86_64
qpid-cpp-client-0.22-42.el7.x86_64
qpid-cpp-server-0.22-42.el7.x86_64
qpid-cpp-server-linearstore-0.22-42.el7.x86_64
qpid-java-client-0.22-7.el7.noarch
qpid-java-common-0.22-7.el7.noarch
qpid-proton-c-0.7-2.el7.x86_64
qpid-qmf-0.22-37.el7.x86_64
qpid-tools-0.22-13.el7.noarch
ruby193-rubygem-katello-1.5.0-93.el7sat.noarch
rubygem-hammer_cli_katello-0.0.4-14.el7sat.noarch
rubygem-smart_proxy_pulp-1.0.1-1.1.el7sat.noarch
s6chima.usersys.redhat.com-qpid-broker-1.0-1.noarch
s6chima.usersys.redhat.com-qpid-client-cert-1.0-1.noarch

How reproducible:

Steps to Reproduce:
1. install puppet on 2 a client and sync
2. check the db by doing below
3.

Actual results:

It looks like this is a bug because the client date is correct but puppet agent is storing the data on the database incorrectly:

[root@s6chima data]# puppet agent -tv
Warning: Setting manifest is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations
(at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations')
Warning: Setting modulepath is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations
(at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations')
Warning: Setting config_version is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations
(at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1095:in `block in issue_deprecations')
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://s6chima.usersys.redhat.com/plugins
Info: Caching catalog for s6chima.usersys.redhat.com
Info: Applying configuration version '1421709200'
Notice: Finished catalog run in 0.24 seconds

Message Load (0.5ms)  SELECT "messages".* FROM "messages" WHERE "messages"."digest" = '7240e6535102e088f32cbdd6dd1c58047be9ca84' LIMIT 1
Source Load (0.4ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = '9191574fdd80d800fd950885475f6235b1e737b8' LIMIT 1
(0.1ms) BEGIN
SQL (0.6ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 4], ["message_id", 3], ["report_id", 712], ["source_id", 2], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]]
(7.6ms) COMMIT
Message Load (0.5ms) SELECT "messages".* FROM "messages" WHERE "messages"."digest" = 'a259b4b60f2993b5b4622e8fb21a86f6fa59ba69' LIMIT 1
(0.1ms) BEGIN
SQL (21.7ms) INSERT INTO "messages" ("digest", "value") VALUES ($1, $2) RETURNING "id" [["digest", "a259b4b60f2993b5b4622e8fb21a86f6fa59ba69"], ["value", "Caching catalog for s6chima.usersys.redhat.com"]]
(17.0ms) COMMIT
Source Load (0.5ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = 'a100926532eb335a499d37a6bdb525c0d49ef68c' LIMIT 1
(0.1ms) BEGIN
SQL (12.8ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 1], ["message_id", 29], ["report_id", 712], ["source_id", 1], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]]
(38.0ms) COMMIT
Message Load (0.4ms) SELECT "messages".* FROM "messages" WHERE "messages"."digest" = '571c5f613633d4208733a07a30224824315d8ffe' LIMIT 1
(0.1ms) BEGIN
SQL (0.2ms) INSERT INTO "messages" ("digest", "value") VALUES ($1, $2) RETURNING "id" [["digest", "571c5f613633d4208733a07a30224824315d8ffe"], ["value", "Applying configuration version '1421709200'"]]
(4.4ms) COMMIT
Source Load (0.3ms) SELECT "sources".* FROM "sources" WHERE "sources"."digest" = 'a100926532eb335a499d37a6bdb525c0d49ef68c' LIMIT 1
(0.2ms) BEGIN
SQL (0.4ms) INSERT INTO "logs" ("created_at", "level_id", "message_id", "report_id", "source_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["created_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00], ["level_id", 1], ["message_id", 30], ["report_id", 712], ["source_id", 1], ["updated_at", Mon, 19 Jan 2015 23:13:20 UTC +00:00]]
(4.9ms) COMMIT

foreman=# \d logs
Table "public.logs"
Column | Type | Modifiers
------------+-----------------------------+---------------------------------------------------
id | integer | not null default nextval('logs_id_seq'::regclass)
source_id | integer |
message_id | integer |
report_id | integer |
level_id | integer |
created_at | timestamp without time zone | not null
updated_at | timestamp without time zone | not null
Indexes:
"logs_pkey" PRIMARY KEY, btree (id)
"index_logs_on_level_id" btree (level_id)
"index_logs_on_message_id" btree (message_id)
"index_logs_on_report_id" btree (report_id)

We look here for the report:

foreman=# select * from logs where id = 869;
id | source_id | message_id | report_id | level_id | created_at | updated_at
-----+-----------+------------+-----------+----------+----------------------------+----------------------------
869 | 1 | 30 | 712 | 1 | 2015-01-19 23:13:20.868694 | 2015-01-19 23:13:20.868694
(1 row)

foreman=# select * from messages where id = 30;
id | value | digest
----+---------------------------------------------+------------------------------------------
30 | Applying configuration version '1421709200' | 571c5f613633d4208733a07a30224824315d8ffe
(1 row)

Here we can see the date is wrong in the database but then we goto the client and verify the time is correct:

foreman=# select * from reports where id = 712;
id | host_id | reported_at | created_at | updated_at | status | metrics
-----+---------+---------------------+----------------------------+----------------------------+--------+----------------------------------------------------------------
712 | 1 | 2015-01-19 23:13:14 | 2015-01-19 23:13:20.661141 | 2015-01-19 23:13:20.661141 | 0 | --- !ruby/hash:ActionController::Parameters + | | | | | | resources: !ruby/hash:ActiveSupport::HashWithIndifferentAccess+ | | | | | | changed: 0 + | | | | | | failed: 0 + | | | | | | failed_to_restart: 0 + | | | | | | out_of_sync: 0 + | | | | | | restarted: 0 + | | | | | | scheduled: 0 + | | | | | | skipped: 0 + | | | | | | total: 1 + | | | | | | time: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | config_retrieval: 1.555408091 + | | | | | | filebucket: 0.000179904 + | | | | | | total: 1.555587995 + | | | | | | changes: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | total: 0 + | | | | | | events: !ruby/hash:ActiveSupport::HashWithIndifferentAccess + | | | | | | failure: 0 + | | | | | | success: 0 + | | | | | | total: 0 + | | | | | |
(1 row)

Time on machine:

[root@s6chima ~]# date
Mon Jan 19 18:21:06 EST 2015


Related issues

Is duplicate of Foreman - Feature #8049: Add suppport for user timezoneClosed2014-10-23

History

#1 Updated by Bryan Kearney over 5 years ago

  • Subject changed from Some Sat 6 reports show incorrect time as GMT to Some Foreman reports show incorrect time as GMT

#2 Updated by Dominic Cleal over 5 years ago

  • Is duplicate of Feature #8049: Add suppport for user timezone added

#3 Updated by Dominic Cleal over 5 years ago

  • Status changed from New to Duplicate

Assuming this is just a request to show a user's timezone (as I can't see anything "incorrect" about UTC storage), this is fixed in #8049.

Also available in: Atom PDF