Description of problem: I have a Hypervisor consumer with the UUID 865d70ef-43df-43c3-b0b1-dc4c0c9b87bc. When I access /consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc, I get a JSON object that includes a "facts" entry, which is a Hash with all the facts of this consumer. When I access /consumers/?uuid=865d70ef-43df-43c3-b0b1-dc4c0c9b87bc, I get a JSON that does not contain "facts". Adding "include=facts" to the query does not help, as this is only a filter, not "fetch this data from the DB" request. GET /consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc => {"created"=>"2018-11-07T10:18:11+0000", "updated"=>"2018-11-07T16:37:32+0000", "id"=>"4028f95e66e9b0860166edadef300140", "uuid"=>"865d70ef-43df-43c3-b0b1-dc4c0c9b87bc", "name"=>"hypervisor.example.com", "username"=>"foreman_admin", "entitlementStatus"=>nil, "serviceLevel"=>"", "owner"=>{"id"=>"4028f95e65c268840165c2691b5b0001", "key"=>"Default_Organization", "displayName"=>"Default Organization", "href"=>"/owners/Default_Organization"}, "environment"=>nil, "entitlementCount"=>0, "facts"=>{"hypervisor.type"=>"VMware ESXi", "cpu.cpu_socket(s)"=>"2", "hypervisor.version"=>"6.7.0"}, "lastCheckin"=>"2018-11-07T16:34:52+0000", "installedProducts"=>[], "canActivate"=>false, "capabilities"=>[], "hypervisorId"=>{"created"=>"2018-11-07T10:18:11+0000", "updated"=>"2018-11-07T10:18:11+0000", "id"=>"4028f95e66e9b0860166edadef32015e", "hypervisorId"=>"hypervisor.example.com", "reporterId"=>nil}, "contentTags"=>[], "autoheal"=>true, "recipientOwnerKey"=>nil, "annotations"=>nil, "contentAccessMode"=>nil, "type"=>{"id"=>"1004", "label"=>"hypervisor", "manifest"=>false}, "idCert"=>nil, "guestIds"=>[], "href"=>"/consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc", "releaseVer"=>{"releaseVer"=>nil}} GET /consumers/?uuid=865d70ef-43df-43c3-b0b1-dc4c0c9b87bc => [{"created"=>"2018-11-07T10:18:11+0000", "updated"=>"2018-11-07T16:37:32+0000", "id"=>"4028f95e66e9b0860166edadef300140", "uuid"=>"865d70ef-43df-43c3-b0b1-dc4c0c9b87bc", "name"=>"hypervisor.example.com", "username"=>"foreman_admin", "entitlementStatus"=>nil, "serviceLevel"=>"", "owner"=>{"id"=>"4028f95e65c268840165c2691b5b0001", "key"=>"Default_Organization", "displayName"=>"Default Organization", "href"=>"/owners/Default_Organization"}, "environment"=>nil, "entitlementCount"=>0, "lastCheckin"=>"2018-11-07T16:34:52+0000", "installedProducts"=>[], "canActivate"=>false, "capabilities"=>[], "hypervisorId"=>{"created"=>"2018-11-07T10:18:11+0000", "updated"=>"2018-11-07T10:18:11+0000", "id"=>"4028f95e66e9b0860166edadef32015e", "hypervisorId"=>"hypervisor.example.com", "reporterId"=>nil}, "contentTags"=>[], "autoheal"=>true, "recipientOwnerKey"=>nil, "annotations"=>nil, "contentAccessMode"=>nil, "type"=>{"id"=>"1004", "label"=>"hypervisor", "manifest"=>false}, "guestIds"=>[], "href"=>"/consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc", "releaseVer"=>{"releaseVer"=>nil}}] Version-Release number of selected component (if applicable): candlepin-2.4.8-1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. GET /consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc 2. GET /consumers/?uuid=865d70ef-43df-43c3-b0b1-dc4c0c9b87bc Actual results: The second query is missing facts Expected results: The queries return identical consumer data Additional info:
This also happens on candlepin-2.5.7-1.el7.noarch.
(In reply to Evgeni Golov from comment #0) > Steps to Reproduce: > 1. GET /consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc > 2. GET /consumers/?uuid=865d70ef-43df-43c3-b0b1-dc4c0c9b87bc > > Actual results: > The second query is missing facts This is by design. Candlepin API endpoints that return bulk/lists of resources, will usually return reduced views of those resources (in this case, one of the omitted fields is facts, which is usually large). Is this still needed? If yes, could you explain the use case for this (Is it Katello needing this)? Thanks, Nikos
(In reply to Nikos Moumoulidis from comment #4) > (In reply to Evgeni Golov from comment #0) > > Steps to Reproduce: > > 1. GET /consumers/865d70ef-43df-43c3-b0b1-dc4c0c9b87bc > > 2. GET /consumers/?uuid=865d70ef-43df-43c3-b0b1-dc4c0c9b87bc > > > > Actual results: > > The second query is missing facts > > This is by design. Candlepin API endpoints that return bulk/lists of > resources, will usually return reduced views of those resources (in this > case, one of the omitted fields is facts, which is usually large). > Is this still needed? If yes, could you explain the use case for this (Is it > Katello needing this)? Yes, this request originates from Katello, where we wanted to know facts about non-RHEL hypervisors (so VMware and friends). You can find some background in https://bugzilla.redhat.com/show_bug.cgi?id=1647762 and https://projects.theforeman.org/issues/25415 We did implement a workaround (fetching each hypervisor individually) in https://github.com/Katello/katello/pull/7821, but that obviously also has a performance impact (probably more than a pure candlepin solution, as it adds TCP/HTTP overhead). So yeah, I still think it would be cool if CP would offer a way to say "give me all HVs *and* their facts", but it's not blocking Katello or anything.
Ok, we'll keep this in the backlog for when we have time to do. One note on using that API though (whenever it is that we fix this): use paging (https://www.candlepinproject.org/docs/candlepin/pagination.html)
Thank you for your interest in Candlepin. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the project, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to re-open this bug, or open a new bug with more up to date details.