Hide Forgot
Created attachment 1222711 [details] lockedtasks on promotion of cv and ccvs Description of problem: The promotion of CV and CCV has been automated. Cronjobs are dimensioned to leave enough time between individual push and promotion tasks. But it seems that locked tasks are currently inevitable Version-Release number of selected component (if applicable): 6.1.10 How reproducible: ALWAYS Steps to Reproduce: 1. pushCV 2. promoteCV 3. pushCCV 4. promoteCCV Actual results: task_locks are rising incrementally the more async jobs are queued. Task resume is not fixing the issue Expected results: Jobs are queued and handled, one after the other. Additional info: Please find trace attached to this bug.
Hi Francisco, I assume that 'push' is doing a content view publish, correct? Are your scripts using hammer-cli or the REST api directly? In the hammer-cli, it appears that both publish and promotion will allow for execution of the operations in a 'synchronous' mode. Have you tried that? E.g. hammer> content-view publish --help Usage: content-view publish [OPTIONS] Options: --async Do not wait for the task --description DESCRIPTION Description for the new published content view version --id ID Content view identifier --name NAME Content view name to search by --organization ORGANIZATION_NAME Organization name to search by --organization-id ORGANIZATION_ID Organization ID to search by --organization-label ORGANIZATION_LABEL Organization label to search by -h, --help print help hammer> content-view version promote --help Usage: content-view version promote [OPTIONS] Options: --async Do not wait for the task --content-view CONTENT_VIEW_NAME Content view name to search by --content-view-id CONTENT_VIEW_ID Content view to search by --description DESCRIPTION The description for the content view version promotion --environment-ids ENVIRONMENT_IDS Identifiers for Lifecycle Environment Comma separated list of values. --force force content view promotion and bypass lifecycle environment restriction --from-lifecycle-environment FROM_ENVIRONMENT_ID Environment name from where to promote its version from (if version is unknown) --from-lifecycle-environment-id FROM_ENVIRONMENT_ID Id of the environment from where to promote its version from (if version is unknown) --id ID Content view version identifier --organization ORGANIZATION_NAME Organization name to search by --organization-id ORGANIZATION_ID organization ID --organization-label ORGANIZATION_LABEL Organization label to search by --to-lifecycle-environment TO_ENVIRONMENT Name of the target environment --to-lifecycle-environment-id TO_ENVIRONMENT_ID Id of the target environment --version VERSION Content view version number -h, --help print help hammer>
Hi Brad, 1) The scripts are using the hammer-cli. [My assumption is, that the cli should perform equal to the REST interface] 2) In an earlier stage of writing those wrappers,publish and promotion where executed in a synchronous way. This led to different difficulties. So the decision was taken to go for --async. I think it has been designed for bulk jobs as pulp is becoming irritated quite quickly.
Hi Francisco, If using the asynchronous execution of the content view publish, the script must monitor and wait for the publish task to finish before performing the content view promotion; otherwise, the lock errors can be expected. When a content view publish is initiated via the UI, it does something similar in that it will monitor the status of the task and block promotions until it completes. That would be similar to running the publish in synchronous mode in the CLI. What were the difficulties or issues with running using synchronous operation?
More than 6 weeks has passed since a NEEDINFO has been requested; therefore, closing this bugzilla. If the issue continues to exist on the latest Satellite 6 release, please feel free to re-open providing additional details. Thanks!