Bug 1576110 - Org admins not able to view system
Summary: Org admins not able to view system
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 2.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: candlepin-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 21:20 UTC by Richard Bernleithner
Modified: 2020-01-03 13:29 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-11 12:09:12 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1314902 0 medium CLOSED 2 virt-who reporting on the same hypervisor using local libvirt and remote libvirt methods creates duplicate systems 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1410601 0 medium CLOSED [RFE] virt-who need to make sure there is only one entry in satellite content host for the same hypervisor when configu... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1566000 0 high CLOSED KVM hypervisor profile does not contain guests running on it in the webui and creates duplicate profile with virt-who-* ... 2021-02-22 00:41:40 UTC

Internal Links: 1314902 1410601 1566000

Description Richard Bernleithner 2018-05-08 21:20:32 UTC
Description of problem: Org admins are not able to view some systems with invalid hypervisor reference 

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


How reproducible:


Steps to Reproduce:
1. Log on as affected org admin (ex:ende_tecnologias)
2. View affected system (ex:609bb124-da3c-4555-ba30-e26d330b40c0)
3.

Actual results:403 error Permission required


Expected results:
Able to view system

Additional info:

This appears to be an issue with these systems pointing to a bad/invalid host system. If you check the system facts for the systems that could not be accessed: 
1. They all have a system fact "virt.uuid" 
2. All of those "virt.uuid" facts point to a hypervisor that doesn't exist 
3. When we lookup these invalid virt.uuids, it can trip a bug on our backend system which causes the backend system to return a real hypervisor, but a hypervisor that isn't owned by the customer 
4. Since the (incorrectly returned) hypervisor isn't owned by the customer, he doesn't have permission to view the details about said hypervisor, which means he can't see the page as a result 

The workaround, until we fix the bug on the backend, is to have the customer update the systems' virt.uuid system facts, so that they point at a correct hypervisor. These are the incorrect values currently associated with each of the systems:

Comment 1 Shayne Riley 2018-05-09 15:08:58 UTC
After digging into this a bit more, I realized I wasn't using virt.uuid correctly. In fact, virt.uuid IS (eventually) referencing a valid hypervisor consumer, however that hypervisor consumer is not owned by the same owner of the guest.

Thus, the reason that the RHSM Web base for the affected system returns a 403 is because when RHSM Web retrieves the host information with:
GET consumers/609bb124-da3c-4555-ba30-e26d330b40c0/host
...the host belongs to a different owner that the user (an org admin) is not a part of.

So, the BZ isn't about a non-existent hypervisor. The BZ is really about how guest consumers are allowed to say they are owned by somebody else's hypervisor.

Comment 2 Shayne Riley 2018-05-09 15:23:45 UTC
Since this issue is about guest consumers being registered against a different owner's hypervisor, is there a fix/workaround that the customer can do until candlepin disallows guests belonging to a different owner's hypervisors? Like, can a virtwho config change be made so that the guests are pointing to a hypervisor they own?

Sidenotes:
- In at least one case, the customer had 0 hypervisors registered to their account. I found this weird, as I would have expected if the owner had guest consumers, then the owner should have had at least one hypervisor too, but nope.
- In another case, one customer's guests were each double registered, one to a hypervisor they owned, and one to a different owner's hypervisor.
- For whatever reason, it it always just one different owner. The guests of one owner could all be hosted by different hypervisors, but all those hypervisors are owned by the one (different) owner.

Comment 6 Shayne Riley 2018-05-22 13:58:52 UTC
How does one retrieve the virt-who configuration? What files do they need to provide?

Comment 12 Barnaby Court 2018-07-11 12:09:12 UTC
Closing as current release given that 2.3.8 just went live in production yesterday. If you are still seeing this issue please reopen.


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