Bug 1022943

While I agree that this would be usability enhancement, I'd not do it automatically - restarting the plugin container means that there is a time window where the agent does not collect any metrics which might not be ideal at certain times of day.

Also, I don't like the idea of requiring to have a group of agents to do the work - some agents might not even be inventoried.

As for the auto-update of the plugins - I'd just add a dialog asking the users whether they want to to do it now and if not remind them of the fact that they need to update the plugins manually on all the agents or wait for the agents to realize there's been a change.

Maybe we could even add a simple schedule for the mass restart of the agents - like upload the plugin and restart all the agents at 2am (in 5hrs, etc).

This is actually going to be quite a bit of work to do properly.

While it would be relatively easy to handle the UI portion of the problem (i.e. add the popups when user updates the plugins using the UI + a bit of backend code to actually do the updates), the user would still be left with no help if they deployed new plugins by copying them into $RHQ_SERVER/plugins. 

In that case, we have no way of finding whether an agent has all the latest versions of the plugins. Simply put, we don't track the updates to plugins at all and we don't have any info on the server about what versions of the plugins each agent has.

So to be able to properly handle both of those usecases, we'd have to start tracking that information - for example on PC startup, we could send up the info about the current plugins (along with MD5s of them) on the agent to the server. The server would then store this information in the DB (new table) and would be able to reason about if agents need updating or not.

A first iteration though might be as easy as adding "Update on Agents" button in the UI and a new method somewhere in the remote API and a notice in the $RHQ_SERVER/plugins/README that the users need to update the plugins on the agents. The user would lack the information about whether the agents are updated or not, but at least would be able to trigger the update.

There is another missing at the moment: it's the plugin scan progress indicator. When you create a resource or schedule an operation, you have an history object which helps you to track the progress. This does not exist with plugin scanning on the server.

In the Maven plugin for agent plugins, there's an "upload" mojo which uses the REST API to send the plugin bits and trigger a plugin scan. If we had a way, in addition to what you're working on now, to track the plugin scan progress, it could be possible to make sure that when your Maven build stops:
* your plugin is uploaded
* the server scan ran
* all agents were updated

I agree, Thomas, but maybe we should track that separately as a standalone RFE.

But it is a major drawback of the API - in fact, I'd like to postpone the fix for this bug to 4.11 just to have time to address your issue, too.

Currently, I just note that exact fact in a javadoc of the methods but I'd much rather see it handled properly than being stuck with an API that doesn't do it right.

(In reply to Lukas Krejci from comment #4)
> maybe we should track that separately as a standalone
> RFE.

Maybe. But it's really the plugin "update" experience as a whole which is bad (understand "update" in its common sense here, not the agent resource operation).

If you upload your plugin bits with the CLI, REST or GUI, you have to remember to run a plugin scan. Then you must watch the logs to make sure it has ended. And eventually you must run the "Update all plugins" op on each resource or a manually crafted agent resources group.

So I think:
* for people who drop files in the /plugins dir, we can't do more than adding some indications in the README file
* for people who use CLI/REST/Remote, we must provide something to monitor plugin scanning; CLI/REST/Remote already provide ways of running "update all plugins" on all agents
* for people who use the GUI, we can add a button in the agent plugins page to trigger the operation on all agents

Being able to know which versions of plugins each agent has is a good thing, I think, but less urgent that plugin scan monitoring.

If we store the installed plugins and their version in the relational DB, bug 1065680 can be done without running the agent "plugins info" operation so it will be much faster.

Other way to find out which agent has which plugins installed would be to store it in ispn cache (every time agent connects to the server, send the list of all the installed plugins).

For bug 1065680, I am considering using ispn..

Pushing to 4.11

merged to master as 5c08e3ff2610

Bulk close of items fixed in RHQ 4.12

If you think this is not solved, then please open a *new* BZ and link to this one.