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):
Steps to Reproduce:
1. Create or edit a monitoring probe
2. Look for the new monitoring data
No data for the new/changed probe is collected. One has to manually push the scout config before changes are effective.
Collection of data for the new/changed probes will be started immediately. No additional steps necessary.
- This RFE is valid for both, Spacewalk and RHN Satellite.
- Already briefly talked with Red Hat's Justin Sherrill about this RFE.
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.
(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.
*** Bug 591166 has been marked as a duplicate of this bug. ***
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.
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.
Mass-moving to space13.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
As of the Spacewalk 2.3 release, monitoring is no longer supported. CLosing.