Bug #11771
closedSaving host without particular status fails
Description
When I save a host that has never had a configuration report:
PG::NotNullViolation: ERROR: null value in column "reported_at" violates not-null constraint DETAIL: Failing row contains (18, HostStatus::ConfigurationStatus, 0, 22, null). : INSERT INTO "host_status" ("host_id", "reported_at", "status", "type") VALUES ($1, $2, $3, $4) RETURNING "id"
I get a similar errror for a host that was reported through configuration management, and never had a BuildStatus.
Updated by Dominic Cleal over 9 years ago
- Related to Feature #10782: Add global status for hosts added
Updated by Dominic Cleal over 9 years ago
- Translation missing: en.field_release set to 63
Do you have a stack trace or any more context to the error? I'm not sure I understand where it's originating from.
Updated by Stephen Benjamin over 9 years ago
It appears to be from this creating a status without a reported_at
https://github.com/theforeman/foreman/blob/develop/app/models/host/managed.rb#L872
Updated by Stephen Benjamin over 9 years ago
Stack trace wasn't really helpful, but:
app/models/concerns/foreman/sti.rb:29:in `save_with_type' app/models/concerns/foreman/sti.rb:29:in `save_with_type' app/controllers/hosts_controller.rb:103:in `block in update' app/models/taxonomy.rb:59:in `block in no_taxonomy_scope' app/models/taxonomy.rb:66:in `block (2 levels) in as_taxonomy' app/models/concerns/foreman/thread_session.rb:147:in `as_location' app/models/taxonomy.rb:65:in `block in as_taxonomy' app/models/concerns/foreman/thread_session.rb:112:in `as_org' app/models/taxonomy.rb:64:in `as_taxonomy' app/models/taxonomy.rb:58:in `no_taxonomy_scope' app/controllers/hosts_controller.rb:100:in `update' app/controllers/concerns/application_shared.rb:13:in `set_timezone' app/models/concerns/foreman/thread_session.rb:32:in `clear_thread' lib/middleware/catch_json_parse_errors.rb:9:in `call'
Updated by Stephen Benjamin over 9 years ago
Sorry, had wrong line selected, this: https://github.com/theforeman/foreman/blob/develop/app/models/host/managed.rb#L882
Edit (domcleal) with SHA: https://github.com/theforeman/foreman/blob/a265235eab649fa76e942205ef4964579532ce72/app/models/host/managed.rb#L882
Updated by Dominic Cleal over 9 years ago
If you can provide any help in reproducing it, it'd be appreciated, I haven't been able to. I suspect there's a specific order in how the host is being created, whether it has or hasn't got reports, and how get_status is being called that triggers it.
My only guess is that this is happening on a report import (though you say no reports), as that calls refresh_statuses, which calls get_status. As far as I can tell, even if a ConfigurationStatus didn't exist, it'd be created and update_timestamp would set reported_at to Time.now. I don't see how it could remain nil.
Updated by Dominic Cleal over 9 years ago
- Status changed from New to Need more information
Updated by Stephen Benjamin about 9 years ago
I continue to see these errors constantly.
For example, provisioning a new machine and then clicking Cancel Build results in:
PG::NotNullViolation: ERROR: null value in column "reported_at" violates not-null constraint DETAIL: Failing row contains (42, HostStatus::ConfigurationStatus, 0, 30, null). : INSERT INTO "host_status" ("host_id", "reported_at", "status", "type") VALUES ($1, $2, $3, $4) RETURNING "id"
Updated by Stephen Benjamin about 9 years ago
Do note I'm on postgresql not SQLite in my dev environment, if that makes a difference.
Updated by Stephen Benjamin about 9 years ago
What I don't understand is this is creating the missing host statuses: https://github.com/theforeman/foreman/blob/a265235eab649fa76e942205ef4964579532ce72/app/models/host/managed.rb#L882
but the reported_at is never set, so how does no one else see this?
The only thing that ever sets reported_at is when the status is refreshed, which doesn't happen for this code.
When I change it to:
new_status = host_statuses.new(:host => self, :type => type.to_s) new_status.refresh
My problems seem to go away.
Updated by Dominic Cleal about 9 years ago
Are you able to trace how #get_status is called? Is it from #refresh_statuses?
If I call refresh_statuses manually on the console, I get a new ConfigurationStatus, and it gets refreshed because it's relevant? (= true).
Updated by Stephen Benjamin about 9 years ago
Yes:
/home/vagrant/foreman/app/models/host/managed.rb:903:in `get_status' /home/vagrant/foreman/app/models/host/managed.rb:921:in `configuration_status' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activesupport-3.2.21/lib/active_support/callbacks.rb:418:in `_run__1205136284132149582__validation__1215673669422551250__callbacks' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activesupport-3.2.21/lib/active_support/callbacks.rb:405:in `__run_callback' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activesupport-3.2.21/lib/active_support/callbacks.rb:385:in `_run_validation_callbacks' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activesupport-3.2.21/lib/active_support/callbacks.rb:81:in `run_callbacks' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activemodel-3.2.21/lib/active_model/validations/callbacks.rb:53:in `run_validations!' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activemodel-3.2.21/lib/active_model/validations.rb:195:in `valid?' /home/vagrant/.rvm/gems/ruby-2.1.5/gems/activerecord-3.2.21/lib/active_record/validations.rb:69:in `valid?' /home/vagrant/foreman/app/models/concerns/orchestration.rb:75:in `valid?' [..snip..] /home/vagrant/foreman/app/models/host/managed.rb:273:in `built' /home/vagrant/foreman/app/controllers/hosts_controller.rb:223:in `cancelBuild'
I created a new host without any configuration management (confirmed host.configuration? is false - so it shouldn't be relevant), then cancelled the build.
Does this work for you? Seems pretty reproducible for me.
Updated by Dominic Cleal about 9 years ago
I can't reproduce it at all unfortunately, I tried creating a new host with provisioning yesterday, then successfully cancelled the build before it built.
The stack trace is interesting, so it appears to be validating configuration_status
. Do you have any plugins installed? Does removing them make any difference (if possible)?
Updated by Alexandre Barth about 9 years ago
I'm facing the same issue. Can't create any host with foreman 1.10 RC1
Updated by Nat Backand about 9 years ago
For me it occurs when the foreman_hooks plugin is used (more specifically: when a /host/managed/create hook is called). At that point I receive the exact same error with 1.10 RC1.
If I move the create hook out of the way adding a new host works fine. As soon as I re-add the create hook it bugs out again with the previously mentioned error.
Updated by Alexandre Barth about 9 years ago
I can confirm this, thank you Nat. When hooks are deactivated, it is working fine.
Updated by Dominic Cleal about 9 years ago
- Status changed from Need more information to Assigned
- Assignee set to Dominic Cleal
Nat Backand wrote:
For me it occurs when the foreman_hooks plugin is used (more specifically: when a /host/managed/create hook is called). At that point I receive the exact same error with 1.10 RC1.
Thanks, I can reproduce it from that. I suspect what's happening is that the API render used in foreman_hooks is calling one of the status methods. Stephen's issue might be similar if not using hooks, it could be a plugin checking the status?
Updated by The Foreman Bot about 9 years ago
- Status changed from Assigned to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2895 added
Updated by Dominic Cleal about 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 3fc47abd9b52acb82189028540ec13e6289e8a03.
Updated by Dominic Cleal almost 9 years ago
- Related to Bug #12954: Foreman puppet report status does not work without a puppet proxy added