Bug 1658284

Summary: [RFE] Allow virt-who-configure plugin to have additional interval options
Product: Red Hat Satellite Reporter: Rich Jerrido <rjerrido>
Component: Virt-who Configure PluginAssignee: Marek Hulan <mhulan>
Status: CLOSED ERRATA QA Contact: Eko <hsun>
Severity: medium Docs Contact: satellite-doc-list
Priority: unspecified    
Version: 6.4.0CC: kuhuang, mhulan, patalber, spetrosi
Target Milestone: 6.6.0Keywords: FutureFeature, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Release Note
Doc Text:
Three new intervals for the virt-who configuration have been added: 24 hours, 2 days, and 3 days. You can now configure Satellite to run the virt-who at the following intervals: every hour, every 2 hours, every 4 hours, every 8 hours, every 12 hours, every 24 hours, every 2 days, or every 3 days.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-22 12:47:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1602034    

Description Rich Jerrido 2018-12-11 16:53:20 UTC
Description of problem:

The least frequent a user can configure the virt-who-configure plugin is to run every 24 hours. In large environments, you may way to run virt-who as infrequent as 2 to 3 days. 

This RFE requests these in the drop down menus as options

Comment 4 Marek Hulan 2018-12-20 20:20:29 UTC
Created redmine issue https://projects.theforeman.org/issues/25747 from this bug

Comment 5 Satellite Program 2018-12-21 11:06:18 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25747 has been resolved.

Comment 6 patalber 2019-02-11 21:11:51 UTC
The case recently attached if for a customer who is interested in shorter intervals than one hour. They would like as short as 1 minute. They have done with manually, but believe that other customers with smaller deployments would benefit.

"Yes, unfortunately there's no events to trigger virt-who to update the guest's UUID immediately after adding a guest with ESX mode.
>>> You can set shorter checking interval as a workaround (--interval option or VIRTWHO_INTERVAL in /etc/sysconfig/virt-who).

We need a 2 minutes interval or so for us to be able to provision new virtual machines that can get registered with the sattelite/pulp.
Hammer cli and the web inteface only let you set higher intervals like : 

[root@satellite-02 ~]# hammer virt-who-config update --name afis-devops --interval 1
Could not create the Virt Who configuration:
  Error: Option '--interval': Value must be one of '60', '120', '240', '480', '720'..

(which are minutes, as observed, not seconds as documented)

Workaround :

I edited the DB directly :

psql: update foreman_virt_who_configure_configs set interval=1 where id = 1;

^ this will result in a 60 secs VIRTWHO_INTERVAL. 

Thus now, unless you modify the conf via web interface you can run 
#hammer virt-who-config deploy --id 1
without overwriting the 60 secs interval. 

And you can now seem to be able use hammer to update the other params without touching the interval.

How can we set lower intervals ? 

I think at least 1, 5 and 30 minutes would be soem useful settings for small deployments."

Comment 8 Rich Jerrido 2019-02-11 22:30:03 UTC
Satellite includes temporary subscriptions which help with provisioning guests which are EXPLICITLY designed to prevent customers from running virt-who too frequently. 

6.2.11 and earlier had a 1 day temporary sub
6.2.12 and newer had a 7 day temporary sub

If the user feels the need to run virt-who very frequently, it is indicative of their activation keys being busted. See https://access.redhat.com/blogs/1169563/posts/2867891 for guidance on configuring activation keys.

Comment 12 errata-xmlrpc 2019-10-22 12:47:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3172