Bug 1655703 - syspurpose attributes should have higher impact than sockets during auto-attach
Summary: syspurpose attributes should have higher impact than sockets during auto-attach
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 2.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Nikos Moumoulidis
QA Contact: Katello QA List
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-03 18:04 UTC by Nikos Moumoulidis
Modified: 2019-03-04 15:52 UTC (History)
3 users (show)

Fixed In Version: candlepin-2.6.2-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1656875 1656876 (view as bug list)
Last Closed: 2019-03-04 15:52:27 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github candlepin candlepin pull 2223 0 None None None 2019-02-06 15:33:36 UTC

Description Nikos Moumoulidis 2018-12-03 18:04:44 UTC
Description of problem:
There are cases during auto-attach, during pool prioritization, that the sockets (or cores, or RAM) attribute can have a higher impact than the support_level attribute (or usage, or other syspurpose attributes too). The syspurpose attributes (usage, support_level, roles, addons), should always have a higher impact than the sockets, cores and ram attributes on pool prioritization during auto-attach.

Version-Release number of selected component (if applicable):
All current versions of candlepin that support the syspurpose feature (2.3.11, 2.5.8, master).

How reproducible:

Steps to Reproduce:
1. Have a system with an installed product 'my_product', the support_level_agreement syspurpose attribute is set to 'mysla', and its cpu.cpu_socket fact has value 1.
2. The server has subscriptions 'pool1' and 'pool2' that both can cover 'my_product'.
3. pool1 provides the support_level 'mysla', and covers 2 sockets.
4. pool2 has no support_level and no socket attributes specified.
5. Run an auto-attach.

Actual results:
The pool 'pool2' was attached, due to the fact that pool1's socket mismatch (2 vs 1) swayed its priority downwards more than how much its support_level match did upwards.

Expected results:
The pool 'pool1' should be attached, because it covers the system's product AND support_level, while any socket match/mismatch should have no effect here.

Additional info:

Comment 1 Nikos Moumoulidis 2019-02-05 13:36:45 UTC
The Steps to Reproduce were not accurate on the description.
In order to reproduce the problem, pool1 must also provide a role and a usage (which the system has not specified), in addition to the sla and sockets.

Note You need to log in before you can comment on or make changes to this bug.