Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1308831

Summary: Creating discovery rule with too long value does not work
Product: Red Hat Satellite Reporter: Oleksandr Shtaier <oshtaier>
Component: Discovery PluginAssignee: Lukas Zapletal <lzap>
Status: CLOSED ERRATA QA Contact: Sachin Ghai <sghai>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.1.6CC: bkearney, sghai
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
URL: http://projects.theforeman.org/issues/13737
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-21 16:44:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot with issue for UI side
none
setting long host_limit in discovery rule raises error: Oops, we're sorry but something went wrong
none
Screenshot with resolved issue none

Description Oleksandr Shtaier 2016-02-16 09:02:15 UTC
Description of problem:
Attempt to create discovery rule entity with too long number (e.g. '456456456546546546546546546546546456456456') for hosts limit field. Get next output in WebUI:
---
PGError: ERROR: value "456456456546546546546546546546546456456456" is out of range for type integer : INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"
---
And using hammer
---
hammer -u my_user -p my_pass discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 2 --hosts-limit 456456456546546546546546546546546456456456
Could not create the rule:
  PGError: ERROR:  value "456456456546546546546546546546546456456456" is out of range for type integer
  : INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"
---


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

How reproducible:
Always

Steps to Reproduce:
1. Create discovery rule with too long hosts limit value

Actual results:
Get an exception which expose some information about internal product structure

Expected results:
Usual field validation used across entire application

Additional info:

Comment 2 Oleksandr Shtaier 2016-02-16 09:05:01 UTC
Created attachment 1127541 [details]
Screenshot with issue for UI side

Comment 3 Oleksandr Shtaier 2016-02-16 09:11:55 UTC
Logs contain same information:
2016-02-16 04:06:43 [W] Operation FAILED: PGError: ERROR:  value "345345345435435435435435345345345345" is out of range for type integer
: INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"

Comment 4 Oleksandr Shtaier 2016-02-16 09:36:47 UTC
Priority field has completely the same behavior, so should be fixed in scope of that defect

Comment 5 Lukas Zapletal 2016-02-16 16:12:28 UTC
Hello Oleksandr,

our DB structure is public, anybody can read it from our git. This is not a security issue.

I confirm this bug, thanks for your report. This is low severity tho.

Comment 6 Oleksandr Shtaier 2016-02-17 08:39:17 UTC
Thanks Lukas for your inputs, that will help me to have better BZ descriptions in future.

Comment 8 Bryan Kearney 2016-02-18 11:10:00 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/13737 has been closed
-------------
Anonymous
Applied in changeset commit:foreman_discovery|43d7643bf0855da8095dc34d2ef726e8cad5f373.

Comment 11 Sachin Ghai 2016-04-06 10:27:15 UTC
Verified sat6.2 beta snap6

I created a discovery rule with long value of 'Hosts limit" and "priority" and UI raises error:

Oops, we're sorry but something went wrong ERROR: value "456456445645645654654654656546546546" is out of range for type integer 


Ideally, an error should raise on same page after submitting the rule.



Also, in hammer, proper error should thrown:

~]# hammer -u admin -p changeme discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 1 --hosts-limit 456456456546546546
Could not create the rule:
  Error: 422 Unprocessable Entity

Comment 12 Sachin Ghai 2016-04-06 10:29:19 UTC
Created attachment 1144155 [details]
setting long host_limit in discovery rule raises error: Oops, we're sorry but something went wrong

Comment 13 Lukas Zapletal 2016-04-06 12:11:52 UTC
Again, I was expecting foreman_discovery to be rebased, but unfortunately it was not and this bug did not make it into 6.2. It was fixed upstream only:

https://github.com/theforeman/foreman_discovery/commit/43d7643bf0855da8095dc34d2ef726e8cad5f373

Reassigning to 6.3.

Comment 16 Bryan Kearney 2016-08-04 20:10:29 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 17 Bryan Kearney 2017-01-05 16:00:52 UTC
This should be in the 6.3 version of discovery. Moving it to ON_QA for verification.

Comment 18 Oleksandr Shtaier 2017-01-12 09:45:50 UTC
Verified for latest snap of 6.3

CLI:
hammer -u admin -p changeme discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 2 --hosts-limit 456456456546546546546546546546546456456456
Could not create the rule:
  Organizations Host group organization OifHjKRTX must also be associated to the discovery rule
  Max count must be less than 2147483648

UI:
Also fixed
Going to attach a screenshot

Comment 19 Oleksandr Shtaier 2017-01-12 09:46:41 UTC
Created attachment 1239833 [details]
Screenshot with resolved issue

Comment 20 Satellite Program 2018-02-21 16:44:36 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336