Plugins » foreman-tasks

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1412307

Description of problem:
Setup: Sat6.2.6 with 4 Capsules in Library environment

Publishing a Content View (with some RPM repo in it) triggers Actions::Katello::ContentView::CapsuleGenerateAndSync task to sync the repo to all Capsules. This step causes memory leak in dynflow_executor process.

When I remove the Capsules from Library LE, the CapsuleGenerateAndSync task is not triggere and the leak is not present.

When I add the Capsules to the LE back and manually invoke in rake console:

ForemanTasks.sync_task(::Actions::Katello::ContentView::CapsuleGenerateAndSync, ::Katello::ContentView.find(3), ::Katello::KTEnvironment.find(1)) while true

(so the task is kicked off repeatedly one after another), the leak is not present.

Version-Release number of selected component (if applicable):
Sat 6.2.6
tfm-rubygem-dynflow-0.8.13.3-2.el7sat.noarch
tfm-rubygem-hammer_cli_foreman_tasks-0.0.10.3-1.el7sat.noarch
rubygem-smart_proxy_dynflow-0.1.3-1.el7sat.noarch
tfm-rubygem-smart_proxy_dynflow_core-0.1.3-1.el7sat.noarch
tfm-rubygem-foreman-tasks-0.7.14.11-1.el7sat.noarch

How reproducible:
100%

Steps to Reproduce:
1. Have 4 Capsules (imho the more the more evident leak) associated to Library LE

2. Run below script that does in a loop:
- creates a CV
- adds a repo (use a small one there)
- publishes the CV
- removes the CV in 2 step (technically, previous CV to let Satellite to sync the content to Caps first)

hmr="hammer -u admin -p redhat "

i=0
while true; do
echo "$(date): working with CV cv_test_$i"
$hmr content-view create --organization=RedHat --name=cv_test_$i
$hmr content-view add-repository --repository-id=1 --organization=RedHat --name=cv_test_$i
$hmr content-view publish --organization=RedHat --name=cv_test_$i
if [ $i -gt 0 ]; then
j=$((i-1))
$hmr content-view remove-from-environment --lifecycle-environment=Library --organization=RedHat --name=cv_test_$j
$hmr content-view delete --organization=RedHat --name=cv_test_$j
fi
i=$((i+1))
sleep 10
done

3. monitor memory usage of dynflow_executor process

Actual results:
memory usage grows over the time

Expected results:
no memory growth

Additional info:
I think same leak is present by triggered Actions::Katello::Repository::CapsuleGenerateAndSync task (seen at a customer, havent reproduced yet) - we shall check that as well