Project

General

Profile

Actions

Bug #12425

closed

Fact import triggers ip conflicts checks, which drives cpu utilization to 100% on smart-proxy

Added by Anonymous almost 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Orchestration
Target version:
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

This is an expensive call, and performing lots of them has a serious impact on smart-proxy. See http://projects.theforeman.org/issues/12392 for more details and discussion.


Related issues 3 (0 open3 closed)

Related to Smart Proxy - Bug #12392: 100% cpu usage on foreman-proxy DHCP callsResolved11/04/2015Actions
Related to Foreman - Bug #13725: Orchestration fails with 409 when there is a MAC DHCP conflictClosedLukas Zapletal02/16/2016Actions
Related to Foreman - Bug #15306: Orchestration does not roll back queued actions if DB error occursClosedShimon Shtein06/06/2016Actions
Actions #1

Updated by Anonymous almost 9 years ago

  • Related to Bug #12392: 100% cpu usage on foreman-proxy DHCP calls added
Actions #2

Updated by Anonymous almost 9 years ago

  • Category set to Orchestration
Actions #3

Updated by Dominic Cleal almost 9 years ago

From #12392, Dmitri says:

It might be possible to set some flag indicating that fact import is in progress, but it's going to be messy.

When saving hosts during fact/report importing we use .save(:validate => false) - not really in an attempt to disable validation, but to disable orchestration (as I understand it). The same isn't done for saving network interfaces, and now that orchestration's in those models, it's running.

If we had a flag to disable orchestration generally instead of disabling validation, we might be able to keep validation on NICs (something we really shouldn't go backwards on by disabling) while disabling orchestration changes at a high level?

Actions #4

Updated by Toni Schmidbauer over 8 years ago

setting ignore_puppet_facts_for_provisioning to true resolved this issue for us.

Actions #5

Updated by Timo Goebel over 8 years ago

https://github.com/theforeman/foreman/commit/4c9529c7bc3c081fb3d0bfdbee09b2e7d6eabc0a#diff-5e596b03372d6df756203e6c69444742

Makes this worse as Foreman now does two calls to smart-proxy during fact import effectively doubling the load.

Actions #6

Updated by The Foreman Bot over 8 years ago

  • Status changed from New to Ready For Testing
  • Assignee set to Timo Goebel
  • Pull request https://github.com/theforeman/foreman/pull/3471 added
Actions #7

Updated by Anonymous over 8 years ago

If you are using ISC dhcpd, I would suggest testing import against changes in https://github.com/theforeman/smart-proxy/pull/409, calls to smart-proxy's dhcp module (when used with ISC dhcpd) no longer incur heavy penalty.

Actions #8

Updated by Dominic Cleal over 8 years ago

  • Related to Bug #13725: Orchestration fails with 409 when there is a MAC DHCP conflict added
Actions #9

Updated by Anonymous over 8 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #10

Updated by Dominic Cleal over 8 years ago

  • Translation missing: en.field_release set to 136
Actions #11

Updated by Brad Buckingham over 8 years ago

  • Bugzilla link set to 1341860
Actions #12

Updated by Lukas Zapletal over 4 years ago

  • Related to Bug #15306: Orchestration does not roll back queued actions if DB error occurs added
Actions #13

Updated by Lukas Zapletal over 4 years ago

  • Triaged set to No

The misbehavior was re-introduced by #15306 fyi. If that's important to you, check it.

Actions #14

Updated by Lukas Zapletal over 4 years ago

Oh I take it back, it resolves the issue.

Actions

Also available in: Atom PDF