Just to note this is still an issue with RHEL7.2

Currently, quiet mode forces the debuglevel to 0 which still causes INFO messages (like the ones mentioned in Comment 0) to be printed.  We should probably fix this by setting it to -2 (only WARNING and above, this is also default for yum-cron) instead.

As a workaround, I'd suggest simply running yum with --debuglevel=-2 in your cron job, which will get rid of those messages.  You may also consider installing yum-cron instead, which uses that debuglevel by default (see /etc/yum/yum-cron.conf for details) and includes a preconfigured daily job.

> As a workaround, I'd suggest simply running yum with --debuglevel=-2 in your
> cron job, which will get rid of those messages.

Please note that for this to work, you also have to leave out the -q option (it would otherwise override --debuglevel back to 0).

Thank you for the suggested workarounds!

I revisited this BZ and learned that --quite using debuglevel of 0 is actually intentional, more info here:
https://bugzilla.redhat.com/show_bug.cgi?id=982088#c2

Basically, the messages related to deltarpm in Comment 0 are important enough to be printed in quite mode.  At least, it has always been like that and there's no good reason to change it now, esp. when there's a simple workaround in Comment 3.

Closing now.

(In reply to Michal Domonkos from comment #7)
> I revisited this BZ and learned that --quite using debuglevel of 0 is

s/quite/quiet/

Just to note that I am seeing this even with the workaround suggested in Comment #3 and a fully updated RHEL7.5 system.  Here's an example email 

-----------------------------------------

Date: Wed,  9 May 2018 08:09:10 -0500 (CDT)
From: "(Cron Daemon)" <root>
To: root
Subject: Cron <root@iem13> yum -y -q --debuglevel=-2 update

Delta RPMs disabled because /usr/bin/applydeltarpm not installed.

------------------------------

(In reply to daryl herzmann from comment #9)
> Just to note that I am seeing this even with the workaround suggested in
> Comment #3 and a fully updated RHEL7.5 system.  Here's an example email 
> 
> -----------------------------------------
> 
> Date: Wed,  9 May 2018 08:09:10 -0500 (CDT)
> From: "(Cron Daemon)" <root>
> To: root
> Subject: Cron <root@iem13> yum -y -q --debuglevel=-2 update
> 
> Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
> 
> ------------------------------

You have to remove the -q option from your command line (see the follow up comment 4).

(In reply to Michal Domonkos from comment #10)
> You have to remove the -q option from your command line (see the follow up
> comment 4).

Oh, I am very sorry for missing that.  Thank you for the instant help and response.

No problem! ;)

So not to hijack my own bugzilla issue, but now that we just migrated locally to Red Hat Satellite 6, new output comes even with --debuglevel=-2 is set.  For example:

Date: Sat, 10 Nov 2018 14:03:40 -0600 (CST)
From: "(Cron Daemon)" <root@myhost>
To: root@myhost
Subject: Cron <root@myhost> yum --debuglevel=-2 -y update

1 local certificate has been deleted.
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
---------------------------------------------------------------

This is a fully updated RHEL 7.6 Server system

(In reply to daryl herzmann from comment #13)
> 1 local certificate has been deleted.

This is a message produced by the subscription-manager plugin.  Looking at the code, it uses the simple print() statement which doesn't honor the debuglevel setting in yum.  That's a bit unfortunate.  If you need that fixed, please file a new BZ against the subscription-manager component (or create a customer ticket).

(In reply to daryl herzmann from comment #13)
> Loaded plugins: product-id, subscription-manager
> Loaded plugins: product-id, subscription-manager
> Loaded plugins: product-id, subscription-manager

These really shouldn't have been printed as they come from yum and should respect the debuglevel setting.  Moreover, the fact that they were repeated 3 times is just strange.

Is this the bug/fix?
```
--- plugins.py.old	2018-11-13 02:56:43.535498267 -0600
+++ plugins.py	2018-11-13 02:57:17.700249880 -0600
@@ -208,7 +208,7 @@
 
         # If we are in verbose mode we get the full 'Loading "blah" plugin' lines
         if (self._plugins and
-            not self.verbose_logger.isEnabledFor(logginglevels.DEBUG_3)):
+            self.verbose_logger.isEnabledFor(logginglevels.DEBUG_3)):
             # Mostly copied from YumOutput._outKeyValFill()
             key = _("Loaded plugins: ")
             val = ", ".join(sorted(self._plugins))
```

No, that won't have any effect.  If yum is running at debug level -2, it shouldn't print the "Loaded plugins:" line at all:

self.verbose_logger.log(logginglevels.INFO_2,
                        fill(val, width=width, initial_indent=key,
                             subsequent_indent=nxt))

Notice logginglevel.INFO_2; this ensures the other argument is only logged (printed in this case) when the debug level is 2 or higher.

(In reply to Michal Domonkos from comment #16)
> No, that won't have any effect. 

That patch fixed the issue for me.

[root@host ~]# yum -y update
rhel-7-server-optional-rpms                              | 1.8 kB     00:00     
rhel-7-server-rpms                                       | 2.0 kB     00:00     
rhel-7-server-satellite-tools-6.4-rpms                   | 2.1 kB     00:00     
rhel-7-server-thirdparty-oracle-java-rpms                | 1.9 kB     00:00     
No packages marked for update
Uploading Enabled Repositories Report
[root@host ~]# yum -y update -q
[root@host ~]# yum -y update --debuglevel=-2
[root@host ~]#

Could you please try running "yum -y update --debuglevel=-2" without the patch?  It should never print the "Loaded plugins" line.

Greetings,  comment #13 was without the patch.  Here's the full session though as you requested...

starting off without the patch
[root@host ~]# yum update --debuglevel=-2
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
[root@host ~]# cp -f /usr/lib/python2.7/site-packages/yum/plugins.py.patched /usr/lib/python2.7/site-packages/yum/plugins.py
[root@host ~]# yum update --debuglevel=-2
[root@host ~]# yum update -q
[root@host ~]# yum update 
rhel-7-server-optional-rpms                              | 1.8 kB     00:00     
rhel-7-server-rpms                                       | 2.0 kB     00:00     
rhel-7-server-satellite-tools-6.4-rpms                   | 2.1 kB     00:00     
rhel-7-server-thirdparty-oracle-java-rpms                | 1.9 kB     00:00     
No packages marked for update
Uploading Enabled Repositories Report
[root@host ~]# 

Based on this host and other systems, that Loaded plugins line is repeated once for each RH repository that is enabled.

(In reply to daryl herzmann from comment #19)
> [root@host ~]# yum update --debuglevel=-2
> Loaded plugins: product-id, subscription-manager
> Loaded plugins: product-id, subscription-manager
> Loaded plugins: product-id, subscription-manager
> Loaded plugins: product-id, subscription-manager

This^ is really strange... I can't seem to reproduce it.  The only explanation I can see is that some plugin is overriding the logging facilities of yum in some nasty way.  Could be the subscription-manager/product-id plugin

Is there any chance you have installed some other yum plugins than those two listed?  Also, can you please try the same but with the plugins disabled?  Like so:

# yum update --debuglevel=-2 --disableplugin=subscription-manager,product-id

(In reply to daryl herzmann from comment #19)
> [root@host ~]# cp -f /usr/lib/python2.7/site-packages/yum/plugins.py.patched

BTW, yes, the patch you made basically disables the message completely (i.e. it's not even passed to the logging module) unless you're running at level DEBUG_3.  While it may work for you in this particular case, it would not be the proper solution for everyone :)

(In reply to Michal Domonkos from comment #20)
> This^ is really strange... I can't seem to reproduce it.  

On a system registered to rhn.redhat.com, I do not reproduce it either.

> The only explanation I can see is that some plugin is overriding the logging
> facilities of yum in some nasty way.  Could be the
> subscription-manager/product-id plugin

I added a print statement to get the `self.verbose_logger.getEffectiveLevel()` and this is what it returns

[root@host ~]# yum update --debuglevel=-2
30
18
Loaded plugins: product-id, subscription-manager
18
Loaded plugins: product-id, subscription-manager
18
Loaded plugins: product-id, subscription-manager
18
Loaded plugins: product-id, subscription-manager
[root@host ~]#


> Is there any chance you have installed some other yum plugins than those two
> listed? 

# ls -l /usr/lib/yum-plugins/
total 88
-rw-r--r--. 1 root root  709 Sep 20 21:35 enabled_repos_upload.py
-rw-r--r--. 2 root root 1067 Sep 20 21:35 enabled_repos_upload.pyc
-rw-r--r--. 2 root root 1067 Sep 20 21:35 enabled_repos_upload.pyo
-rw-r--r--. 1 root root 1045 Sep 20 21:35 package_upload.py
-rw-r--r--. 2 root root  780 Sep 20 21:35 package_upload.pyc
-rw-r--r--. 2 root root  780 Sep 20 21:35 package_upload.pyo
-rw-r--r--. 1 root root 5693 Sep  5 12:50 product-id.py
-rw-r--r--. 2 root root 3821 Sep  5 12:56 product-id.pyc
-rw-r--r--. 2 root root 3821 Sep  5 12:56 product-id.pyo
-rw-r--r--. 1 root root 5379 Sep  5 12:50 search-disabled-repos.py
-rw-r--r--. 2 root root 5728 Sep  5 12:56 search-disabled-repos.pyc
-rw-r--r--. 2 root root 5728 Sep  5 12:56 search-disabled-repos.pyo
-rw-r--r--. 1 root root 6785 Sep  5 12:50 subscription-manager.py
-rw-r--r--. 2 root root 5792 Sep  5 12:56 subscription-manager.pyc
-rw-r--r--. 2 root root 5792 Sep  5 12:56 subscription-manager.pyo


> Also, can you please try the same but with the plugins disabled? 
> Like so:
> 
> # yum update --debuglevel=-2 --disableplugin=subscription-manager,product-id

[root@host ~]# yum update --debuglevel=-2 --disableplugin=subscription-manager,product-id
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
Loaded plugins: product-id, subscription-manager
[root@host ~]#

(In reply to daryl herzmann from comment #22)
> I added a print statement to get the
> `self.verbose_logger.getEffectiveLevel()` and this is what it returns
> 
> [root@host ~]# yum update --debuglevel=-2
> 30
> 18
> Loaded plugins: product-id, subscription-manager
> 18
> Loaded plugins: product-id, subscription-manager
> 18
> Loaded plugins: product-id, subscription-manager
> 18
> Loaded plugins: product-id, subscription-manager
> [root@host ~]#

Thank you, this explains it quite well.  Some plugin is messing up with the verbose_logger instance.

> # ls -l /usr/lib/yum-plugins/
> total 88
> -rw-r--r--. 1 root root  709 Sep 20 21:35 enabled_repos_upload.py
> -rw-r--r--. 2 root root 1067 Sep 20 21:35 enabled_repos_upload.pyc
> -rw-r--r--. 2 root root 1067 Sep 20 21:35 enabled_repos_upload.pyo
> -rw-r--r--. 1 root root 1045 Sep 20 21:35 package_upload.py
> -rw-r--r--. 2 root root  780 Sep 20 21:35 package_upload.pyc
> -rw-r--r--. 2 root root  780 Sep 20 21:35 package_upload.pyo

These I don't recognize and they might as well be the culprit.

> > Also, can you please try the same but with the plugins disabled? 
> > Like so:
> > 
> > # yum update --debuglevel=-2 --disableplugin=subscription-manager,product-id

What about:
# yum update --debuglevel=-2 --disableplugin=enabled_repos_upload,package_upload

(In reply to Michal Domonkos from comment #23)

> These I don't recognize and they might as well be the culprit.

[root@host yum-plugins]# rpm -qf package_upload.py
katello-host-tools-3.3.5-3.el7sat.noarch

These would have shown up as new when we migrated to RH Satellite 6 and installed katello-agent

> What about:
> # yum update --debuglevel=-2
> --disableplugin=enabled_repos_upload,package_upload

that worked, with my debug print still set here:

[root@host yum-plugins]# yum update --debuglevel=-2 --disableplugin=enabled_repos_upload,package_upload
30
[root@host yum-plugins]#

The problem is isolated to the `enabled_repos_upload` plugin.  Will see if I can resolve why it is causing trouble.

Eh, above my paygrade :(  I see in enabled_report a call to `yb = yum.YumBase()` for each enabled repo, which would explain why the print out appears to match the number of enabled repos.  Thanks for all the rapid responses today.

Right, I actually just came to the same conclusion after trying to debug this on a VM with a the enabled_repos_upload plugin (even though Satellite is not domain either).

Please, consider filing a bug against the Satellite product and katello-host-tools component if it's something you'd like to have fixed.

Thanks!

(In reply to Michal Domonkos from comment #27)
(even though Satellite is not domain either).

s/is not/is not my/

(In reply to Michal Domonkos from comment #27)
> Please, consider filing a bug against the Satellite product and
> katello-host-tools component if it's something you'd like to have fixed.

Thanks, done here:

https://bugzilla.redhat.com/show_bug.cgi?id=1649476

and this bug is related too it seems.

https://bugzilla.redhat.com/show_bug.cgi?id=1625649

I would like to revisit this bug.

I understand that, as explained in https://bugzilla.redhat.com/show_bug.cgi?id=982088#c2, "--quiet" should really means "--debuglevel=0"; however, I see no good reasons why the messages about deltarpms should be printed when "--quiet" is used. This is expecially true for purely informative messages, as "Delta RPMs disabled because /usr/bin/applydeltarpm not installed" or "Delta RPMs reduced ..." and the likes.

So I suggest using INFO_2 for these informative deltarpm messages. Please note that messages about deltarpm anomalies (ie: "Some delta RPMs failed to download or rebuild") aready uses WARNING or CRITIAL priority.

Please note that the RHEL-7.7 release is now in the Maintenance Support 1 Phase:
https://access.redhat.com/support/policy/updates/errata/#Maintenance_Support_1_Phase

If you consider this issue important, please contact your Red Hat support representative.