Project

Profile

Help

Issue #4793

Locking does not work as expected with Publications

Added by dalley 12 days ago. Updated 2 days ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Severity:
2. Medium
Version:
Platform Release:
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 53

Description

Expected behavior: A publication can be created immediately after kicking off a sync task, because it will wait for the prior task to complete, at which point there will be a repository version to use.

Actual behavior:

# Create a new Foo repository version by syncing repository from remote.

http POST :24817$REMOTE_HREF'sync/' repository=$REPO_HREF
HTTP/1.1 202 Accepted
Allow: POST, OPTIONS
Connection: close
Content-Length: 67
Content-Type: application/json
Date: Tue, 07 May 2019 19:32:29 GMT
Server: gunicorn/19.9.0
Vary: Accept, Cookie
X-Frame-Options: SAMEORIGIN

{
    "task": "/pulp/api/v3/tasks/69e8be69-7754-4c87-88ed-e295fd01e643/" 
}

# sleep 2

# Create a publication for the repository

http POST :24817/pulp/api/v3/publications/rpm/rpm/ repository=$REPO_HREF
HTTP/1.1 400 Bad Request
Allow: GET, POST, HEAD, OPTIONS
Connection: close
Content-Length: 87
Content-Type: application/json
Date: Tue, 07 May 2019 19:32:30 GMT
Server: gunicorn/19.9.0
Vary: Accept, Cookie
X-Frame-Options: SAMEORIGIN

{
    "non_field_errors": [
        "Repository has no version available to create Publication from" 
    ]
}

Uncommenting the "sleep" statement will make this script work.

This is probably not an issue with task locking, but rather with the synchronous code in the viewset.

History

#1 Updated by dalley 12 days ago

  • Description updated (diff)

#2 Updated by amacdona@redhat.com 10 days ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 53

#3 Updated by amacdona@redhat.com 10 days ago

  • Related to Issue #4562: Source installs should fail if a plugin requires a newer version of pulpcore-plugin or pulpcore than is checked out added

#4 Updated by amacdona@redhat.com 10 days ago

  • Related to deleted (Issue #4562: Source installs should fail if a plugin requires a newer version of pulpcore-plugin or pulpcore than is checked out)

#5 Updated by daviddavis 2 days ago

I looked at the code and it seems that publishing a repo is just a shorthand for publishing its latest repository version since publish tasks are currently locking on a repository version. I suppose if we wanted to make this change, we'd have to lock on repositories but that seems less optimal. What about leaving this code as-is and supporting auto-publish instead?

#6 Updated by bmbouter 2 days ago

daviddavis wrote:

I looked at the code and it seems that publishing a repo is just a shorthand for publishing its latest repository version since publish tasks are currently locking on a repository version. I suppose if we wanted to make this change, we'd have to lock on repositories but that seems less optimal. What about leaving this code as-is and supporting auto-publish instead?

I agree. +1 to leaving as-is and adding a 'publisher' field to PublicationDistribution which will provide the auto-publish feature. If we want to do that should this story be closed (for posterity) and a new one opened?

Please register to edit this issue

Also available in: Atom PDF