Bug 1492148 - Failed messages are logged as information messages by the application.
Summary: Failed messages are logged as information messages by the application.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Provisioning
Version: 6.2.11
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: 6.4.0
Assignee: Ivan Necas
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-15 15:23 UTC by Giridhar
Modified: 2021-12-10 15:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 19:12:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21055 0 None None None 2017-09-21 16:08:40 UTC

Description Giridhar 2017-09-15 15:23:05 UTC
Description of problem:

While provisioning a machine GUI returns nothing and also the failed messages are logged as application information messages

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

6.2.11

How reproducible:

Always 100% at the customer end.

Steps to Reproduce:
1.Click on new host
2.Select the organization
3.Select the subnet which is not associated with organization
4. provide all the required details and click on submit

Actual results:

GUI does not throw any error and also in the log messages, we failed messages are printed as information messages.

Expected results:

GUI should throw some error and also in the log messages, we failed messages should be printed as error messages messages.

Additional info:

Comment 3 Ivan Necas 2017-09-21 16:08:38 UTC
Created redmine issue http://projects.theforeman.org/issues/21055 from this bug

Comment 4 Ivan Necas 2017-09-21 16:19:27 UTC
The issue is still in upstream, I've sent a patch to fit it. This was more specific to the host taxonomy validator, other error messages are propagated properly to the UI: therefore I've updated the title of this BZ.

I believe there was an update on how the options for the subnet are generated in sat 6.3 (I was not able to reproduce the case, where the I would be able to select subnet that doesn't belong to the organization: the only way I could reproduce it was actually to update the code to always trigger the validator, Therefore I don't consider this a priority for 6.3.

Comment 5 Satellite Program 2017-09-21 18:08:47 UTC
Upstream bug assigned to inecas

Comment 6 Satellite Program 2017-09-21 18:08:50 UTC
Upstream bug assigned to inecas

Comment 9 Satellite Program 2018-04-06 18:10:02 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21055 has been resolved.

Comment 11 Ivan Necas 2018-09-24 10:29:34 UTC
To reproduce the situation in 6.3, one needs to:

1. assign a host interface to a subnet
2. the foreman UI now doesn't allow assigning the subnet to host when taxonomies mismatch, therefore it needs to be set via foreman-rake console:

s = Subnet.find_by(name: "mysubnet")
s.organizations = []
s.locations = []
s.save

3. go to the host edit page and try to save it

You should see the error in the interfaces tab + "Failed to save: Interfaces.subnet is not defined for host's location, Interfaces.subnet is not defined for host's organization" in /var/log/foreman/production.log should be logged with 'error' level

Note: In case there is no other subnet avaiable in the domain, it's not possible to change it in the host form after step 2 is performed. However, given the corner-case as this one, I don't think is effective to try to fix that: the right fix in that case would be looking at host details page and updating the assigned subnet to have the org/location to set right.

Comment 12 Lukáš Hellebrandt 2018-09-24 11:12:53 UTC
Verified with Sat 6.4 snap 22.

This is not reproducible anymore as per comment 4.

Tested taxonomy-validator changes to test sanity. Used steps from comment 11. The error is now propagated to WUI (no pop-up but the field is marked as invalid in red) and production.log now says:

2018-09-24T13:08:51 [W|app|db321] Not queueing Nic::Managed: ["Subnet is not defined for host's location", "Subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Nic::Managed: ["Subnet is not defined for host's location", "Subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Nic::Managed: ["Subnet is not defined for host's location", "Subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Host::Managed: ["Interfaces.subnet is not defined for host's location", "Interfaces.subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Host::Managed: ["Interfaces.subnet is not defined for host's location", "Interfaces.subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Host::Managed: ["Interfaces.subnet is not defined for host's location", "Interfaces.subnet is not defined for host's organization"]
2018-09-24T13:08:51 [W|app|db321] Not queueing Discovery reboot: Interfaces.subnet is not defined for host's location and Interfaces.subnet is not defined for host's organization
2018-09-24T13:08:51 [E|app|db321] Failed to save: Interfaces.subnet is not defined for host's location, Interfaces.subnet is not defined for host's organization

=> Marked as error => Correct

Comment 13 Bryan Kearney 2018-10-16 19:12:45 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:2927


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