While running yum update to install/upgrade packages to 6.2 from 6.1, it creates bash scripts in /tmp/ directory like: 

/tmp/sclPliDkB 
/tmp/tmp.BGgtiKxsvJ 
/tmp/rpm-tmp.1U8aWH

these scripts contain rake tasks like: 

db:migrate
db:seed
apipie:cache:index 

For the customers having large satellite setup these tasks take long time to complete. While these tasks are running in the backend there is no user friendly message on the console, so it make user think that  " yum update" command is stuck or not responding. 

Since we are running all these above tasks while running # satellite-installer --upgrade so can we skip then while updating packages? 

If not, there should be user friendly error message on the console so admins will wait till it completes.

Attaching image from a test system for reference:

Created attachment 1366001 [details]
Image attached

Hi Brad,

Yeah, this issue is seen while 6.2 to 6.3 upgrade too. 

Here are some details from one of my recent upgrade 6.2.7 to 6.2.12 

This is the script which get created under /var/tmp/

# cat /var/tmp/rpm-tmp.dM27yT 
# We need to run the db:migrate after the install transaction
# always attempt to reencrypt after update in case new fields can be encrypted
/usr/sbin/foreman-rake db:migrate db:encrypt_all >> /var/log/foreman/db_migrate.log 2>&1 || :
/usr/sbin/foreman-rake db:seed >> /var/log/foreman/db_seed.log 2>&1 || :
/usr/sbin/foreman-rake apipie:cache:index >> /var/log/foreman/apipie_cache.log 2>&1 || :
(/sbin/service foreman status && /sbin/service foreman restart) >/dev/null 2>&1



# cat /tmp/tmp.q1hd3u46nC 
rake db:migrate db:encrypt_all

# date ; cat /tmp/tmp.1YxDGNuRI2 
Wed Dec 13 05:22:36 IST 2017
rake apipie:cache:index

# date ; cat /tmp/tmp.0WDLlgAm0y 
Wed Dec 13 05:24:14 IST 2017
rake db:migrate

# date ; cat /tmp/tmp.uugUYwHdqX  
Wed Dec 13 05:24:34 IST 2017
rake db:seed

# date ; cat /tmp/tmp.DQagGFOFML 
Wed Dec 13 05:24:58 IST 2017
rake apipie:cache:index

# date ; cat /tmp/tmp.SdPGWupI6p 
Wed Dec 13 05:26:37 IST 2017
rake db:migrate

# date ; cat /tmp/tmp.T7YSLIW9by 
Wed Dec 13 05:26:58 IST 2017
rake db:seed

# date ; cat /tmp/tmp.iNIq65b0zu 
Wed Dec 13 05:27:23 IST 2017
rake apipie:cache:index

# date ; cat /tmp/tmp.h3oe3OYPx4 
Wed Dec 13 05:29:37 IST 2017
rake db:seed

# date ; cat /tmp/tmp.LN5v3Ok0AO 
Wed Dec 13 05:30:06 IST 2017
rake ldap:refresh_usergroups

# date ; cat /tmp/tmp.tE3NdUdZ6R 
Wed Dec 13 05:30:11 IST 2017
rake apipie:cache:index

# date ; cat /tmp/tmp.WeDUj2hb4N 
Wed Dec 13 05:30:15 IST 2017
rake trends:counter

# date ; cat /tmp/tmp.tE3NdUdZ6R 
Wed Dec 13 05:30:22 IST 2017
rake apipie:cache:index

# date ; cat /tmp/tmp.UKaU3YA3Xm 
Wed Dec 13 05:32:20 IST 2017
rake db:migrate

# date ; cat /tmp/tmp.uwTR0BKM4M 
Wed Dec 13 05:32:51 IST 2017
rake db:seed

# date ; cat /tmp/tmp.OHqyik9BUh 
Wed Dec 13 05:33:11 IST 2017
rake apipie:cache

# date ; cat /tmp/tmp.OHqyik9BUh 
Wed Dec 13 05:38:19 IST 2017
rake apipie:cache

Here we can see that the yum update command was stuck for 16+ mins with no output on the console. 

I will try to get similar details for 6.2 to 6.3 upgrade and update in this bz.

I'm suggesting this for foreman-maintain: the idea would be to set something (such as env variable or maybe a file present on the file-system) to skip this steps, as we will run them via the upgrade process later anyway.

This task would consist of two steps:

1. update the packaging spec to allow skipping this parts (such as here https://github.com/theforeman/foreman-packaging/blob/rpm/1.16/foreman/foreman.spec#L862), it's needed to be aware of the fact

2. teach foreman-maintain how to use the way to disable this steps, introduced in 1.

Acutally, thinking more about this, while the foreman-maintain addition would be useful, as we would prevent running all the rake scripts in the rpm scripts, I think the solution might be just teaching the foreman macros how to check, if the particular rake task was already run during the transaction: this would prevent from need to be run twice.

The problem is every plugin adds the steps about db:migrate and apipie:cache into their post-trans phase. This results in running this multiple times. The solution might be:

1. in %postrans, every affected rake run would create some mark that it was run. The subsequent rake runs would notice this and would skip it's call again

2. in %pretrans, we would clear the marks from previous run to allow the posttrans to be run in case of the new update session

The mark could be achieved by a simple file, that would contain all the rake calls that were already run during the update.

Created redmine issue http://projects.theforeman.org/issues/21965 from this bug

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.