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

John Mazzitelli jmazzite at redhat.com
Wed Mar 14 13:19:05 UTC 2012


> 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 
> 

I don't know how to do it - but having it float around in the resource
configuration is not how it should be done (if that's what you mean by
"having a special property __event". We need to be careful not to
pollute the resource configuration with special properties. That would
require special handling all the way through - from the UI (to not show
it) to the PC/plugin (so they are aware to expect something IN ADDITION
TO the resource configuration metadata). This needs to be done a
different way.

> 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.

This is something a little more along the lines that we should do.
Perhaps we need another entity linked to resource - similar to
ResourceError but one that indicates "Runtime Status" of the resource or
something like that (and if that entity is not empty, we'd put a "blue
ball" or something on the UI, like the yellow triangle for when a
non-empty ResourceError exists). Plugins would be free to populate this
anyway they want for their particular resource (just like we can put
whatever we want in the ResourceError - although I don't think plugins
themselves can do this, can they? it would be cool if they can).

> 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.

This would require more push APIs from the plugin side. We would have to
add another plugin container context to the ResourceContext object that
the plugin can interact with. This allows the plugin to call into the PC
to allow it to say, "tell the server I just finished the reload". That
"event" would go into this new ResourceError like entity (or perhaps it
clears it out so the UI can stop showing "the blue ball").

This entire concept needs a good design effort behind it since it
involves everything from UI all the way down to the plugin and
everything in between (schema changes, server side API, plugin container
API). Also would need UXD input so we can figure out the best way to
display this to the user. This is a good 3.1 or 3.1+ feature.




More information about the rhq-devel mailing list