Project

General

Profile

Refactor #18975

Store info about relevancy of a host status in database

Added by Ivan Necas over 5 years ago. Updated over 5 years ago.

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

Description

Right now, we need to calculate the host status on per-host basis. This leads to:

1. N+1 queries when the relevant method needs to fetch additional data (example http://projects.theforeman.org/issues/18842)
2. not ability to perform a relevant search that would respect the relevancy (example http://projects.theforeman.org/issues/18974)


Related issues

Related to Foreman Remote Execution - Bug #18842: Avoid N+1 query in foreman hosts index by declaring proper scopeNew2017-03-08
Related to Foreman - Bug #18974: Host configuration chart should not include irrelevan hostsNew2017-03-22
Related to Katello - Bug #18845: Avoid N+1 query in foreman hosts index by declaring proper scopeClosed2017-03-08

History

#1 Updated by Ivan Necas over 5 years ago

  • Related to Bug #18842: Avoid N+1 query in foreman hosts index by declaring proper scope added

#2 Updated by Ivan Necas over 5 years ago

  • Related to Bug #18974: Host configuration chart should not include irrelevan hosts added

#3 Updated by Ohad Levy over 5 years ago

can't we just revert to the old behavior by using the host status attribute as a global status? and change the UI that it fetch the status info only if needed (or async)?

#4 Updated by Marek Hulán over 5 years ago

As discussed today in person, the problem is not the relevant? method and it can't be stored in DB since some host statuses change their statuses during runtime based on current time or application configuration. E.g. code from build status

    def to_status(options = {})
      if waiting_for_build?
        if token_expired?
          TOKEN_EXPIRED
        else
          PENDING
        end
      else
        BUILT
      end
    end

    def relevant?(options = {})
      SETTINGS[:unattended] && host.managed?
    end

We should first avoid this pattern so that TOKEN_EXPIRED and PENDING are flipped correctly at the right time. For that we need to have some optional timestamp that we set during the status updated. This timestamp would define when the refresh on this status should be considered. Then we need async worker that finds all host statuses with such timestamp in past and run the refresh. The same applies to configuration status that gets out of sync after some period in which we don't receive puppet report. We should just bump the timestamp by the interval from SETTINGS on every report processing.

can't we just revert to the old behavior by using the host status attribute as a global status? and change the UI that it fetch the status info only if needed (or async)?

This is the old behavior, the build and configuration status were based on time. The only change that happened is that we moved statuses from host table to host_statuses table so plugin can introduce their own. I don't think that's the main problem. The main problem is that we can't rely on status stored in DB with current (and old) status implementation and we need to verify whether the status e.g. represented by code 1 actually means "Pending" or "Token expired".

#5 Updated by Shimon Shtein over 5 years ago

  • Related to Bug #18845: Avoid N+1 query in foreman hosts index by declaring proper scope added

Also available in: Atom PDF