Bug 585248

Summary:	RFE: Scout Config Push should be done automatically in the background
Product:	[Community] Spacewalk	Reporter:	Sandro Mathys <sandro>
Component:	WebUI	Assignee:	Tomas Lestach <tlestach>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	0.8	CC:	cperry, ggainey, jpazdziora, tao
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-30 16:00:42 UTC	Type:	---
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:	737830

Description Sandro Mathys 2010-04-23 14:26:51 UTC

Description of problem:
Whenever a user changes a monitoring probe, he's then forced to do a manual scout config push which seems unnecessary and really is a usability killer since it's a pretty unnecessary step and is often forgotten (and almost always forgotten if the probe was editing from within the system view). This RFE suggests to change this behaviour to automatically push the scout config whenever a probe is edited.

This would also make the Scout Config Push mask in the WebUI obsolete but please make sure at least the satellite administrators will have the possibility to see if the push in the background ever fails.

Version-Release number of selected component (if applicable):
Spacewalk 0.x
Satellite 5.y.z

How reproducible:
Always

Steps to Reproduce:
1. Create or edit a monitoring probe
2. Look for the new monitoring data
  
Actual results:
No data for the new/changed probe is collected. One has to manually push the scout config before changes are effective.

Expected results:
Collection of data for the new/changed probes will be started immediately. No additional steps necessary.

Additional info:
- This RFE is valid for both, Spacewalk and RHN Satellite.
- Already briefly talked with Red Hat's Justin Sherrill about this RFE.

Comment 1 Jan Pazdziora 2010-05-26 19:46:14 UTC

I don't think I'm in favor of automatic push. There seems to be some use in the fact that all the changes done to the monitoring probes are pushed at once. Plus to make the administrator aware that they should do the push and watch the results of that push (sometimes for multiple scouts), and act on any errors.

On the other hand, the WebUI could certainly use changes to make it much more clear that given probe won't be run in the way it is currently shown because the push has not been done. Or generally that scout push is needed.

So I'd like to change this RFE to read: Every monitoring WebUI page should display an information at the top

   When finished editing monitoring probes, do not forged to <a href="/network/monitoring/scout/index.pxt">push the config changes to scout</a>.

whenever there has been a change done to probes that needs a scout push to be propagated.

Comment 2 Sandro Mathys 2010-05-26 20:51:54 UTC

(In reply to comment #1)
> Plus to make the administrator aware that they should do the push and watch the
> results of that push (sometimes for multiple scouts), and act on any errors.

Right. Except that a push is always done for all orgs, not just the administrator's. So if administrator A makes probe changes in org 1 and admin B in org 2, as soon as A pushed the scout config B lost control. So why pretend that the administrator has total control if he hasn't?

I think every administrator should be aware that he has to act on errors (and watch out for them) after he changed anything (like probes) - I don't see why he's only aware of that with an additional manual push. Like if you apply errata - there's an extra confirm button but that's it. With your logic an additional 'push errata update' button in a totally different part of the webUI would be necessary here so the administrator is aware that he has to act on errors with the installation of updates.

> On the other hand, the WebUI could certainly use changes to make it much more
> clear that given probe won't be run in the way it is currently shown because
> the push has not been done. Or generally that scout push is needed.

Agreed if the manual pushing is kept. But instead of just a warning in the monitoring tab the health symbol should be a different one - instead of the <?> right now. So the <?> symbol should only be used if the probe's state is unclear/not working but there should be a different symbol if the state is unclear because a push is needed.

Comment 3 Miroslav Suchý 2010-05-27 07:21:25 UTC

*** Bug 591166 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Suchý 2010-05-27 07:26:15 UTC

While I understood reasoning in #1 I would like to keep both behaviour. Manual push and automatic push. I would like to add to Monitoring setup one new option "Automatic Scout Config Push" and make it enabled by default. And those who want to manually control the push (very small number of customers) will have to disable this feature.

Comment 5 Sandro Mathys 2010-05-27 07:35:52 UTC

Making both possible with automatic as the new default would be fine with me. Keep in mind to hide the scout config push tab if manual pushing is disabled but still allow access to the pubkey of the scout, please.

Comment 6 Jan Pazdziora 2010-11-19 16:03:09 UTC

Mass-moving to space13.

Comment 7 Miroslav Suchý 2011-04-11 07:31:49 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 8 Miroslav Suchý 2011-04-11 07:36:31 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 9 Jan Pazdziora 2011-07-20 11:49:32 UTC

Aligning under space16.

Comment 10 Grant Gainey 2015-03-30 16:00:42 UTC

As of the Spacewalk 2.3 release, monitoring is no longer supported.  CLosing.