Bug 1492148

Summary:	Failed messages are logged as information messages by the application.
Product:	Red Hat Satellite	Reporter:	Giridhar <gkonda>
Component:	Provisioning	Assignee:	Ivan Necas <inecas>
Status:	CLOSED ERRATA	QA Contact:	Lukáš Hellebrandt <lhellebr>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.2.11	CC:	inecas, lhellebr
Target Milestone:	6.4.0	Keywords:	Triaged
Target Release:	Unused
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-16 19:12:45 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:

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