Project

Profile

Help

Issue #1490

closed

Errata IDs not showing up correctly in the API

Added by paji@redhat.com over 6 years ago. Updated over 3 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
High
Assignee:
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
3. High
Version:
Master
Platform Release:
2.8.0
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

When I run the equivalent of following in 2.6

RestClient.post "https://katello-pulp-nightly.example.com/pulp/api/v2/content/units/erratum/search/", "{\"criteria\":{}}", "Accept"=>"*/*; q=0.5, application/xml", "Accept-Encoding"=>"gzip, deflate", "Content-Length"=>"15", "accept"=>"application/json", "content_type"=>"application/json"

I get a list of errata back with each errata row having the following keys

["_href", "issued", "references", "_content_type_id", "id", "from", "severity", "title", "children", "version", "reboot_suggested", "type", "pkglist", "status", "updated", "description", "_last_updated", "pushcount", "_storage_path", "rights", "solution", "summary", "release", "_id"]

However in 2.8 the same call returns errata with each row having the keys of

["_href", "issued", "references", "pulp_user_metadata", "_content_type_id", "children", "from", "severity", "title", "version", "reboot_suggested", "type", "pkglist", "status", "updated", "errata_id", "description", "_last_updated", "pushcount", "downloaded", "_storage_path", "rights", "solution", "summary", "release", "_id"]

This breaks api compatibility for existing users and needs to be fixed.


Related issues

Related to RPM Support - Issue #1478: POST request to /pulp/api/v2/repositories/<reponame>/search/units/ does not transform id correctly when unit results returnedCLOSED - CURRENTRELEASEsemyersActions
Actions #1

Updated by paji@redhat.com over 6 years ago

One field that stands out amongst the differences here is errata_id in 2.8 vs id in 2.6

Actions #2

Updated by semyers over 6 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to semyers

Quick diff for lazy eyeballs...

Items in the 2.6 set not in the 2.8 set: {'id'}
Items in the 2.8 set not in the 2.6 set: {'downloaded', 'errata_id', 'pulp_user_metadata'}

Actions #3

Updated by mhrivnak over 6 years ago

  • Priority changed from Normal to High
  • Severity changed from 2. Medium to 3. High
  • Platform Release set to 2.8.0
  • Triaged changed from No to Yes
Actions #4

Updated by semyers over 6 years ago

  • Related to Issue #1478: POST request to /pulp/api/v2/repositories/<reponame>/search/units/ does not transform id correctly when unit results returned added

Added by semyers over 6 years ago

Revision 6fdf3c7d

content unit search views use content unit serializers

Recent changes in the pymongo > mongoengine conversion have resulted in different ways to represent mongo documents in the REST api views; the correct way is to use the mongoengine Document serializers wherever possible. When that isn't possible, remap_fields_with_serializer exists to use the information in a mongoengine serializer to modify serialized results properly.

Anything that is using the serialization functions in pulp.server.webservices.views.serializers.content should automaticaly benefit from this change, which implicitly fixes redmine #1490.

These changes can also be used to benefit views that don't call the existing serialization functions by explicitly using the new remap_fields_with_serializer function as-needed, such as RepoUnitSearch, which will help (but not fix) redmine #1478.

fixes #1490 https://pulp.plan.io/issues/1490

re #1478 https://pulp.plan.io/issues/1478

Added by semyers over 6 years ago

Revision 6fdf3c7d

content unit search views use content unit serializers

Recent changes in the pymongo > mongoengine conversion have resulted in different ways to represent mongo documents in the REST api views; the correct way is to use the mongoengine Document serializers wherever possible. When that isn't possible, remap_fields_with_serializer exists to use the information in a mongoengine serializer to modify serialized results properly.

Anything that is using the serialization functions in pulp.server.webservices.views.serializers.content should automaticaly benefit from this change, which implicitly fixes redmine #1490.

These changes can also be used to benefit views that don't call the existing serialization functions by explicitly using the new remap_fields_with_serializer function as-needed, such as RepoUnitSearch, which will help (but not fix) redmine #1478.

fixes #1490 https://pulp.plan.io/issues/1490

re #1478 https://pulp.plan.io/issues/1478

Actions #5

Updated by semyers over 6 years ago

  • Status changed from ASSIGNED to MODIFIED
  • % Done changed from 0 to 100
Actions #6

Updated by semyers over 6 years ago

"old" pymongo objects weren't been serialized when coming out of some search api views dealing with content units. The solution (after normalizing the model serializer location to model.SERIALIZER) was to create a helper function to serialize those objects using the field remapping rules from the newer mongoengine serializers. Most search views will transparently benefit from this change, with the issue in #1478 being a noted exception.

Actions #7

Updated by rbarlow over 6 years ago

  • Status changed from MODIFIED to 5
Actions #8

Updated by dkliban@redhat.com over 6 years ago

  • Status changed from 5 to CLOSED - CURRENTRELEASE
Actions #9

Updated by bmbouter over 3 years ago

  • Tags Pulp 2 added

Also available in: Atom PDF