Out of band signaling of information (config , operations , .. )

Heiko W.Rupp hrupp at redhat.com
Wed Mar 14 11:13:17 UTC 2012


Hi,

this is related to [1], where a config change (via resource-configuration tab or perhaps operation) puts the
target resource (an AS7 server in this case) into a state where the change will only be applied after a reload/restart.
A similar situation can be constructed for e.g. Apache httpd, where a change in conf.d/*.conf is only applied after
a 'service httpd reload'.
One can of course always just issue a reload after the config change, but in most cases this is not desired - just 
think of the case where the config is applied to all servers in a cluster and you don't want to reboot them all at the
very same time, but in a rolling manner.

So when the as7-server tells us that a reload is required for a config change to be applied, we also need to signal 
this to the user. This could be done in band in the configuration, but our users do not expect to watch the configuration
when the outcome is the green "config change was successful".

So we need a way to signal that to the user out of band. There are two things involved here

1) delivering that 'event' to the server and UI
2) presenting it


If the 'event' would be sent around via Configuration e.g. as a special property with name __event , we would need to make
sure, that 
- clearing that flag by a reboot would not trigger a new config version being recorded in history
- it is not shown in the config editor
Instead its content could be shown in the red/yellow/green bar area e.g. in blue 

Another way to present the information could be to populate the resource error so that the yellow triangle shows
up. This does not really feel right though.

An additional question that comes to mind is where to display the information hierarchy-wise. If I e.g. change the
config of a web-connector and it needs a reload to come active, the need-reload flag should probably be displayed
on the whole hierarchy or perhaps on all children of the server until the server has been reloaded.

Which brings me to the point on how to cancel above flag/event when a reload operation has successfully been 
invoked. For the resource error side, the plugin can perhaps just clear it out, while this is not easily possible for
a configuration based approach, as the automatic config checking only happens from time to time.

Thoughts?

   Heiko


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=802810

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer:  Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera



More information about the rhq-devel mailing list