Bug 1824588
| Summary: | Sat6 inventory uploaded removes displayname set by insights-client | ||
|---|---|---|---|
| Product: | Red Hat Hybrid Cloud Console (console.redhat.com) | Reporter: | Peter Vreman <peter.vreman> |
| Component: | Inventory | Assignee: | Shaun Dunning <sdunning> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mirek Długosz <mzalewsk> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | ecerqueira, ihands, khoes, lphiri, sjagtap |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-20 14:36:40 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1122832 | ||
|
Description
Peter Vreman
2020-04-16 11:00:23 UTC
Afterards trying to repair the displayname with the Insights-Client fails with a ISE500: ------ 2020-04-16 10:58:28,649 DEBUG insights.client.connection NO PROXY: None 2020-04-16 10:58:28,654 DEBUG insights.client.utilities Found /etc/insights-client/machine-id 2020-04-16 10:58:28,655 NETWORK insights.client.connection GET https://fibssat6sb.hag.hilti.com:443/redhat_access/r/insights/v1/systems/ff89f7fc-51ea-49f7-8ece-d9d97332b0ae 2020-04-16 10:59:28,758 NETWORK insights.client.connection PUT https://fibssat6sb.hag.hilti.com:443/redhat_access/r/insights/v1/systems/ff89f7fc-51ea-49f7-8ece-d9d97332b0ae 2020-04-16 11:00:28,868 ERROR insights.client.connection Unable to set display name: 500 {"status":500,"error":"Internal Server Error"} vrempet-admin@li-lc-1441 ~ ------ Thanks Peter, taking a look at this issue with the involved teams. Do you know if this started happening recently and was working previously? Or are you unsure? Hi Peter, We are continuing to look. One thing we noticed though is the System exists in the new Inventory but not in the Classic inventory. At the moment we still send uploads to the Classic API first, then forward the uploads along (to maintain backwards compatibility for Classic users). Classic required an explicit POST for Systems to be created and the new Inventory does not... can you try and run --register on one of the Systems and see if this resolves the 500 for you? And also check if the display name is updated? Peter, Even bugging up my system on purpose I am unable to replicate the error message you received. I see: 2020-04-16 12:34:04,446 DEBUG insights.client.connection NO PROXY: None 2020-04-16 12:34:04,447 DEBUG insights.client.utilities Found /etc/insights-client/machine-id 2020-04-16 12:34:04,447 NETWORK insights.client.connection GET https://fifi-satlab1.usersys.redhat.com:443/redhat_access/r/insights/v1/systems/8611ac1a-b3af-4ddf-b3bb-1b0714feb26b 2020-04-16 12:34:04,629 NETWORK insights.client.connection PUT https://fifi-satlab1.usersys.redhat.com:443/redhat_access/r/insights/v1/systems/8611ac1a-b3af-4ddf-b3bb-1b0714feb26b 2020-04-16 12:34:04,760 ERROR insights.client.connection System not found. Please run insights-client --register. Can you verify the client egg and core version you are running? Ian,
I see it for all 4 systems up-dated sstems connected to my sat6sb that is upgraded last week to rhel7.8 and yesterday sat6 from 6.6 to 6.7 and i also tried myself for the first time manually to upload the inventory from sat6. But that should also be scheduled in the background.
The upload issue with ISE500 i see only on the systems connect to the sat6.7 instance on rhel7.8.
On other VMs connected to Sat6.6 instance Insights upload is working fine as usual.
The client issue is a bug in Sat6.7. I guess it is proxy related will open a dedicated case for sat6 that the upgrade is failing to migrate a working configuration:
-----
2020-04-16T03:49:18 [I|app|707d3d02] Started PUT "/redhat_access/r/insights/v1/systems/ff89f7fc-51ea-49f7-8ece-d9d97332b0ae" for 10.92.14.89 at 2020-04-16 03:49:18 +0000
2020-04-16T03:49:18 [I|app|707d3d02] Processing by RedhatAccess::Api::MachineTelemetryApiController#proxy as JSON
2020-04-16T03:49:18 [I|app|707d3d02] Parameters: {"display_name"=>"[crash/LI/IPS/OSDev-7.7-latest] li-lc-1441.hag.hilti.com", "path"=>"v1/systems/ff89f7fc-51ea-49f7-8ece-d9d97332b0ae", "machine_telemetry_api"=>{"display_name"=>"[crash/LI/IPS/
OSDev-7.7-latest] li-lc-1441.hag.hilti.com"}}
2020-04-16T03:49:35 [E|app|60cc2356] RedhatAccess::Telemetry::PortalClient: Caught HTTP error when proxying call to tapi: Timed out connecting to server
2020-04-16T03:49:35 [W|app|60cc2356] Action failed
2020-04-16T03:49:35 [I|app|60cc2356] Completed 500 Internal Server Error in 60177ms (ActiveRecord: 21.1ms)
2020-04-16T03:49:35 [F|app|60cc2356]
-----
Peter
This BZ is only then on the issue that since sat6.7 the display name is removed, by i guess the sat6.7 upgrade. And as inisghts-client cannot run it was not able to repair and hide the bug. So for that case it is good that insights-client was not running as it would have hidden the bug. Hi Peter, Thanks for separating out the 500 status errors. We have determined the issue with regards to the display name issue. We believe there is in fact an issue wrt the Sat inventory plugin overwriting the Insights Client or web interface set display_names. We are going to move fast to take some corrective action here. Thanks for the report. Ian, Thanks for confirming you have reproduced the issue. I did also a test to change the display name in the UI and then the sat6 upload also overwrites it. Peter Hi Peter, The inventory team pushed out a hotfix that should resolve this issue. Our own tests show that this is resolved, can you please ack on you end if you have a moment? Thanks. Ian Confirming it is fixed. The displayname is not replaced anymore after i clicked upload from sat6 inventory. Super performance of DevOps workstyle to have this already fixed <48 hours! Peter Thanks for the ack Peter!
> Super performance of DevOps workstyle to have this already fixed <48 hours!
Thanks here goes to the Eng team... we passed along the message :D
|