Issue #4793
closedLocking does not work as expected with Publications
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.
Related issues
Updated by amacdona@redhat.com over 5 years ago
- Triaged changed from No to Yes
- Sprint set to Sprint 53
Updated by amacdona@redhat.com over 5 years 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
Updated by amacdona@redhat.com over 5 years 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)
Updated by daviddavis over 5 years 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?
Updated by bmbouter over 5 years 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?
Updated by amacdona@redhat.com over 5 years ago
- Sprint changed from Sprint 53 to Sprint 54
Updated by ttereshc over 5 years ago
- Status changed from NEW to CLOSED - WONTFIX
Here is the documentation issue which should state how to deal with those situations conveniently.
https://pulp.plan.io/issues/5006
Updated by ttereshc over 5 years ago
- Related to Issue #5006: A publication can't be created immediately after kicking off a sync task added