Project

Profile

Help

Issue #1966

fast-forward publishes produce unexpected reports

Added by Ichimonji10 over 5 years ago. Updated over 2 years ago.

Status:
CLOSED - NOTABUG
Priority:
Normal
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Master
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

Let's say one does the following:

1. Create and sync an RPM repository.
2. Publish the repo.
3. Publish the repo again.

The first publish should be a full publish, and the second should be a fast-forward publish. Pulp does this. One can verify this is so by finding the last task spawned by the publish operation, and verifying its ['results']['details'] attribute. It looks like this under Pulp 2.8:

[{u'description': u'Copying files',
  u'details': u'',
  u'error_details': [],
  u'items_total': 1,
  u'num_failures': 0,
  u'num_processed': 1,
  u'num_success': 1,
  u'state': u'FINISHED',
  u'step_id': u'6d8e55b6-dbbd-4c1a-a481-f94e7ffdf2c4',
  u'step_type': u'save_tar'},
 {u'description': u'Initializing repo metadata',
  u'details': u'',
  u'error_details': [],
  u'items_total': 1,
  u'num_failures': 0,
  u'num_processed': 1,
  u'num_success': 1,
  u'state': u'FINISHED',
  u'step_id': u'6992dde8-3ec8-4fd8-9386-05331579161a',
  u'step_type': u'initialize_repo_metadata'},
 {u'description': u'Publishing Distribution files',
  u'details': u'',
  u'error_details': [],
  u'items_total': 0,
  u'num_failures': 0,
  u'num_processed': 0,
  u'num_success': 0,
  u'state': u'FINISHED',
  u'step_id': u'77b27c90-a763-429b-a22e-ae6048ce57cb',
  u'step_type': u'distribution'},
 {u'description': u'Publishing RPMs',
  u'details': u'',
  u'error_details': [],
  u'items_total': 0,
  u'num_failures': 0,
  u'num_processed': 0,  # NOTE: num_processed is zero
  u'num_success': 0,
  u'state': u'FINISHED',
  u'step_id': u'b44c9e02-c4c3-40f7-bb7c-3040f4ca99ee',
  u'step_type': u'rpms'},
 {'...': '...'}]

It looks like this under Pulp 2.9:

u'Skipped. Nothing changed since last publish'

This is problematic because:

  • it breaks client code that parses task details to find out what's done, and
  • clients that update themselves to accommodate the new response format must now deal with localization issues. Really, parsing prose in a programmatic way is a Bad Idea.

If the intent is to communicate that a fast forward publish has occurred, either:

  • we should keep the existing format for task details, or
  • we should return an empty list.

History

#2 Updated by ipanova@redhat.com over 5 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ipanova@redhat.com

#3 Updated by ipanova@redhat.com over 5 years ago

  • Status changed from ASSIGNED to CLOSED - NOTABUG

After discussion with Jeremy we agreed that since this is a part of new feature some new behaviour and deviation are tolerable and expected.
Valid issue would be to open is - refactor publish results(expected,skipped, error, failed) to be all consistent.

#4 Updated by bmbouter over 2 years ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF