So, I did some research on the codebase for possible pain points for this change. It looks completely doable, albeit that's going to be quite a bit work to get it correctly. As for backend details, I've been thinking about having a "base" entity, provably something like MiddlewareEntity, which would have the fields in common for all entities as usual, as well as a "metadata" field exposed as a JSON, and then we can work from there to get everything else working.
There are some questions that I have:
* What kind of metadata are we talking about, is it static or more of schema-less data?
* Are we talking only about showing the data, or also editing, filtering and searching?
* How should the backend present it to the frontend? As a normal controller or through an API?
* In case we have more metadata in the future to be available for all entities, how should we migrate the older ones?
* Is there a way to present JSON Schema (
http://json-schema.org/) from the Agent to MiQ, or at least to have that defined before we start working on it?
* How are "capabilities" supposed to be shown to MiQ? Let's say, a server has the support on running operations, can we assume that this will be signaled somewhere to us?
* How much of the control on what MiQ can do should be available on miq-side and how much should be provided by the agent? Let's say, right now manageiq has the knowledge on whether a server is mutable or not, and based on that knowledge we decide if we should enable server operations or not. I don't think that's ideal, and in my mind the ideal case would be having something like that on the data:
{ "capabilities": ["operations", "metrics"] }
And from that we should show the correct info/actions on the page.
As a bottom point, I like this feature very much, as it can reduce the amount of info ManageIQ has to act upon, by moving responsibilities from it to the agent.