[Hawkular-dev] change notification: parameter metadata is in a different place

Jay Shaughnessy jshaughn at redhat.com
Wed Aug 24 12:02:13 EDT 2016


I think the hawkular-ruby-client [gem] does use the generic properties 
when building an OperationDefinition.  And these definitions are used by 
HawkFX. I don't think MIQ is affected because I don't think it's yet 
using these OperationDefinitions from the gem.  There could be MIQ code 
being written now, or in PRs that could be affected by this change, I'm 
not sure.  But I think we could update the gem code and HawkFX can just 
use the updated gem.  With the updated gem code in place I think we 
could merge the agent work.  I can work on a PR for that...


On 8/23/2016 11:49 PM, John Mazzitelli wrote:
> Recently, we added the ability for the Hawkular WildFly Agent to advertise what parameters can get passed to an operation by storing parameter metadata in the operation type's general properties.
>
> However, Hawkular-Inventory provides an "official" place to store this data. Rather than have general properties host this metadata, H-Inventory wants parameters stored in a child data entity called "parameterTypes" under the operation type. [3]
>
> The agent now does it this "official" way. However, to avoid clients from breaking before they can fix themselves and get parameters from this new location, the agent retains the original parameter metadata in general properties as well.
>
> But of course we do not want the agent to store copies of the same metadata in two different locations in Hawkular-Inventory. So a JIRA [1] has been created to remove the parameters from general properties - a PR has been submitted and is able to be merged [2].
>
> So, clients that look up operation parameters inside H-Inventory need to look at the parameterTypes data entity child and NOT look for them in general properties. If you have a client (MiQ?, Ruby gem?, Hawkfx?) that obtains parameter metadata from operation types' general properties, it should be fixed because once this PR is merged, parameter information will no longer exist in general properties.
>
> -- John Mazz
>
> [1] https://issues.jboss.org/browse/HWKAGENT-130
>
> [2] https://github.com/hawkular/hawkular-agent/pull/244
>
> [3] This is what the "official" parameters types entity looks like - parameters are stored in a data entity child called "parameterTypes" under the operation type - this example shows the parameters for the WildFly Server's "Shutdown" operation (the parameters are "timeout" and "restart"):
>
> {
>    "path": "/t;hawkular/f;74ceb88e-4740-49f8-9e46-8d192dc6e14a/rt;WildFly%20Server/ot;Shutdown/d;parameterTypes",
>    "name": "parameterTypes",
>    "identityHash": "1ad5d5963d6978975e958de5abcb49f778695f",
>    "contentHash": "5ff8951bc6a6ab6483f69ec0ab139d5a76e22c",
>    "syncHash": "27163827304a2c50e31b9ce2ee74e5e32f396d58",
>    "value": {
>      "timeout": {
>        "type": "int",
>        "description": "Timeout in seconds to allow active connections to drain",
>        "defaultValue": "0",
>        "required": false
>      },
>      "restart": {
>        "type": "bool",
>        "description": "Should the server be restarted after shutdown?",
>        "defaultValue": "false",
>        "required": false
>      }
>    }
> }
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160824/8ee08602/attachment.html 


More information about the hawkular-dev mailing list