Add functionality to list operations definitions in inventory about hawkular-client-ruby HOT 11 CLOSED

I'll add the list operations, however, not all the available operations are stored in the inventory. Currently, for WF there are: JDR, Reload, Deploy and Shutdown. But one can also, CRUD the deployments, JDBC datasources and drivers (these are not listed in inventory).

I was talking with Mazz about it and it's by design.

<mazz> anyone interacting with the HAwkular WildFly Agent will "just know" :) what it can support. This is our way of getting away from the pluggable agent we had in RHQ..

Oh, and there is also related JIRA on the inventory side: https://issues.jboss.org/browse/HWKINVENT-179

So, as far I understand it well, currently the operation types stored in the inventory are there only for the "security" reasosns, because every time, the agent executes the DMR operation, it also checks if it's white-listed in the inventory for given resource type.

from hawkular-client-ruby.

I don't think this is right @jmazzitelli - why do we have Inventory when it is not used?
There may be many agents or uses of the current Hawkular-agent in the future where we can't know in advance what operations are available or not.
And then when you expect that someone writes a very specific UI per operation, you may be right, that the user needs to know the peculiarities of each operation. And then, the operation tag in the agent config is currently not self-explanatory either; I just recall where some additional data may be passed.

from hawkular-client-ruby.

The Hawkular WildFly Agent is not pluggable - so there is no way to add new websocket commands. The agent supports a fixed set of websocket command - these are defined here as JSON schemas: https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular-command-gateway-api/src/main/resources/schema

So this means the agent can support things like "Deploy Application" and "Add Datasource" and "Remove Datasource" and "Generate JDR Report". As we add new websocket commands, we'd get new websocket JSON schemas.

What you see in the standalone.xml metadata are DMR operations that are available on each DMR resource - like "Start", "Stop". These we store in inventory (without parameter metadata - just the operation names). If someone wants to invoke a DMR Operation, they pass over the websocket a JSON command ExecuteOperationRequest and pass in one of the operation names you need there (along with any parameters).

It doesn't make sense to have the websocket commands in the metadata of standalone.xml - because it doesn't get you anything. Suppose, for the sake of argument, we put all of our websocket commands in inventory under the main WildFly Server resource's operations - you will see "Add Datasource" and "Remove Datasource". OK, then what? The client still needs to know what JSON message is associated with the websocket command, the client still needs to build the JSON and know what JSON response to expect. The client will see "oh, there is an Add Datasource operation" - but it still needs to know "in order to tell the agent to execute the "Add Datasource" operation, I need to pass a JSON message called "AddDatasourceRequest" - I need to stream in the datasource jar, I need to expect a AddDatasourceResponse message back".

In other words, this isn't RHQ where every operation is pluggable and is invoked via the same remote API. We purposefully said we didn't need to implement such a generic, pluggable model for the Hawkular WildFly Agent - we just expect the clients (like the old Hawkular UI) to "just know" what websocket commands are available in the agent, what JSON messages need to be passed in for those commands, etc, etc.

Now, if you just want to use metadata for documentation purposes only, we can add those. But of course, now the agent will need to know a particular operation is not REALLY a DMR operation but just a websocket command and so if someone tries to send "ExecuteOperationRequest" with the operation name "Add Datasource" the agent will need to spit an error out. And, of course, this is going to be super confusing to people because "I see an operation called "Add Datasource" - how come it doesn't work when I pass it in via the ExecuteOperationRequest JSON command???"

from hawkular-client-ruby.

I was certainly not talking about DMR operations, but the ones that are sent like 'Add Datasource' or 'Reload'.
Speaking of confusion the Reload vs reload thing started this a long time ago :-)

With your logic, there is also no need to register metrics in inventory, because its crazy form can be deducted from the MR~bla pattern and everyone working with Hawkular knows that some WildFly-foo-time is in 100th of a second.

I fear that we are (again) encoding too much knowledge in integration layers of one single consumer (ManageIQ) and leaving out other possible consumers, which have to do all the encoding and riddling again.

from hawkular-client-ruby.

I can certainly add those websocket operations as metadata, but of course this means the client (the one looking up the operations metadata in inventory) will need to say to himself "If i want to execute the "Start" or "Stop" or "Reload" operation, I need to do so by passing in that name via ExecuteOperationRequest JSON. But if I want to execute the "Add Datasource" operation, I need to pass in the AddDatasourceRequest JSON".

We tried mimicing RHQ operations by providing the metadata to expose DMR operations (or JMX operations in the world of Jolokia/JMX) - the websocket commands are more like the remote agent service API (which in RHQ is only accessible to the RHQ Server; in Hawkular, these remote agent APIs are now accessible to any client - that's where the difference comes in to play).

from hawkular-client-ruby.

"If i want to execute the "Start" or "Stop" or "Reload" operation, I need to do so by passing in that name via ExecuteOperationRequest JSON. But if I want to execute the "Add Datasource" operation, I need to pass in the AddDatasourceRequest JSON".

It should be possible to store any JSON metadata with the operation type in the inventory. I can't 100% confirm, because the api is currently broken, but from what I've seen in the tests, it should be doable - https://git.io/vrUcq . @metlos can you please correct me if I am wrong?

JSON schema is good and we can store it actually in the inventory too as some kind of contract definitions, or store only the link to the github + sha, perhaps?

from hawkular-client-ruby.

First, I'd like to point out that inventory currently stores operation definitions - that is what the operations should look like, not the actual individual invocations. The definition includes operation name, the parameter types and the expected return type. The latter two are specified using a json schema(1 schema for the parameters and 1 schema for the return type), so yes, you can encode quite a lot of information about the format of the requests in inventory. The only bit missing is where to send the actual payloads of actual operation "instances". Currently that isn't inventory's concern (and btw command gateway could theoretically validate the operations against the schema stored in inventory prior to sending it to the agents).

from hawkular-client-ruby.

@metlos It clearly says "operation definitions" in the subject - doesn't it? :-) (Which what I meant, but was to sloppy to correctly articulate in the first place).

@jmazzitelli Why can't we just add the targeted schema then? I think the information in inventory should be self-contained enough to figure out what is needed and returned. Looks like we are close.

from hawkular-client-ruby.

So this doesn't get lost, can someone write a HWKAGENT JIRA ( https://issues.jboss.org/projects/HWKAGENT/issues ) on this explaining what it is we'd like to see in the inventory metadata?

from hawkular-client-ruby.

Done - https://issues.jboss.org/projects/HWKAGENT/issues/HWKAGENT-87

from hawkular-client-ruby.

Implemented in #63

from hawkular-client-ruby.