-
Bug
-
Resolution: Done
-
Undefined
-
None
-
2.3
-
None
-
False
-
-
False
-
-
Description
After editing the requirements.yml file for a different version range, PAH fails to sync the new content
Current workaround: Trigger the sync with optimize=false
curl https://huburl/api/galaxy/content/community/v3/sync/ -X POST -u admin:password -k--data-raw '{ optimize=false }'
Key Dependency Versions
{
"available_versions": {
"v3": "v3/",
"pulp-v3": "pulp/api/v3/"
},
"server_version": "4.6.4",
"galaxy_ng_version": "4.6.4",
"galaxy_ng_commit": "",
"galaxy_importer_version": "0.4.5",
"pulp_core_version": "3.21.3",
"pulp_ansible_version": "0.15.0",
"pulp_container_version": "2.14.1"
}
Steps to Reproduce
1) create requirements.yml
---
collections:
- name: community.general
version: ">=6.4.0"
2) configure PAH to sync with with file
3) validate the versions synced on the api
/api/galaxy/content/community/v3/plugin/ansible/content/community/collections/index/community/general/versions/
4) edit the requirements.yml with a new version range
---
collections:
- name: community.general
version: ">=6.0.0"
5) repeat steps 2 and 3
Actual Behavior
Only 3 collection versions are synced
{
"meta": {
"count": 3
},
Expected Behavior
8 collections
{
"meta": {
"count": 8
},
[AAH-2322] Failure to sync new content in PAH after editing requirements.yml
abakshi1 I tested again on the same environment in which the case was opened originally and could not reproduce the behavior.
We may close this issue for now and I can reopen it in can this happens again.
One note, would it be possible to add the debug on the code as a feature from Galaxy with an easier toggle on the UI/Settings?
Editing the files is usually not an easy experience when dealing with customers' environments.
lbenedit1@redhat.com can you take a look at the most recent comment with regards to the last_sync_timestamp?
This is supposed to be fixed by https://github.com/pulp/pulp_ansible/issues/1177 which landed in 0.15.0.
Can you verify that the last_sync_timestamp was not cleared after editing the remote? If you have access to the installed code, can you add some trace logging (or a debugger breakpoint) in `pulp_ansible/app/models.py::CollectionRemote::_reset_repository_last_synced_metadata_time` to verify it get's called?
cc lbenedit1@redhat.com Is this still an issue? If yes, then can you give more information about the last_sync_timestamp that Matthias asked?
lbenedit1@redhat.com trying later and having it work may be explained because the server timestamp has changed, so that will make the client proceed with the sync.
rhn-engineering-mdellweg
I repeated the same tests described in the description and this time the collection count changed.
This suggests an intermittent behavior while syncing collections.
Is it possible to verify the logs for past executions?
This is supposed to be fixed by https://github.com/pulp/pulp_ansible/issues/1177 which landed in 0.15.0.
Can you verify that the last_sync_timestamp was not cleared after editing the remote? If you have access to the installed code, can you add some trace logging (or a debugger breakpoint) in `pulp_ansible/app/models.py::CollectionRemote::_reset_repository_last_synced_metadata_time` to verify it get's called?
Workaround based on the suggestion from rochacbruno@redhat.com after reviewing the code https://github.com/pulp/pulp_ansible/blob/9ddecd0a5dd0813be274f817e7fd33f63d966ab7/pulp_ansible/app/tasks/collections.py#L1014-L1051
lbenedit1@redhat.com perfect, closing the issue then.
can you please open a new ticket for the feature request that is more elaborate and has details??