<div dir="ltr"><div>Hello Guys,</div><div><br></div><div>This is another update to the proof of concept, and today we are doing big improvements to cover other parts of the representation that we did not cover yet: fetching data from Hawkular, and turning that into entities/views.</div><div><br></div><div>First, let's look at fetching data from Hawkular's Inventory:</div><div><br></div><div># Create Client</div><div>client = Hawkular::Client.new(</div><div> entrypoint: '<a href="http://localhost:8080">http://localhost:8080</a>',</div><div> credentials: { username: 'jdoe', password: 'password' },</div><div> options: { tenant: 'hawkular' }</div><div>)</div><div><br></div><div># Get all feeds available on the server</div><div>feeds = client.inventory.list_feeds</div><div><br></div><div># Get all resources</div><div>feeds.map do |feed|</div><div> # We get the resources for the feed</div><div> resources = client.inventory.list_resources_for_feed(feed, true)</div><div> # Then we make them presentable</div><div> HawkularResourceCollection.new(resources).prepare</div><div>end</div><div>The first new thing here is HawkularResourceCollection, which does the following:</div><div><br></div><div>Gets the raw representation of the properties defined by Hawkular</div><div>This is necessary because we want to use everything the server gives us, not only what the gem decides to expose.</div><div>Creates the entities by mapping the data (we will cover that soon).</div><div>Merge other resource properties for the servers.</div><div>This last step is a little more complicated: there are two kinds of resources that we get from the inventory: servers (like WildFly Servers) and what I call resources: java runtime, operating systems, and so on. We need some properties on the server that are exposed from the runtime/os, like immutability controls, so we merge those to all the servers on the feed.</div><div><br></div><div>To map the data to the entities, we use EntityMapper, a class that does exactly this mapping. Besides that, it does name transformation for properties, feed extracting, unescaping of paths, and returning a hash. When we need to persist anything, this is the data that we generate for the field, so persisting and fetching data from the db can looks like this:</div><div><br></div><div># Getting data from the db, raw_hash being our json field to save the response</div><div>server = MiddlewareServer.last</div><div>entity = Entity.constantize(server.raw_hash)</div><div><br></div><div># And persisting an entity to the db</div><div>server.update(raw_hash: entity.data)</div><div>The generated hash is then fed to Entity.constantize, which returns the entities we will use to render.</div><div><br></div><div>So, we have the data, and we have the entities. I have a standalone setup running, generated by hawkinit, and the response contains the following:</div><div><br></div><div>A WildFly Server</div><div>The Java Runtime</div><div>The Operating System</div><div>Which will use the following entities/views to render (refer to old emails/README.md for more on this):</div><div><br></div><div><img src="cid:ii_j5cw3e4j0_15d61b04ddecff4f" width="412" height="63"><br><br></div><div><br></div><div>Well, that's it. If you download the code at the github repo, you can see this in action, by just running the server and visiting ./ It will list everything hawkular found running, in pretty pretty json using the defined views.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 19, 2017 at 12:59 PM, Caina Costa <span dir="ltr"><<a href="mailto:cacosta@redhat.com" target="_blank">cacosta@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So, an update:<div><br></div><div>I implemented support of json and yaml schemas to generate views dynamically. A schema looks like this:</div><div><br></div><div><div>{</div><div> "summary": [</div><div> {"name": "id"},</div><div> {"name": "active", "alias": "is_active"},</div><div> {"name": "full_name", "alias": "name"}</div><div> ],</div><div> "foo": {"name": "foo"}</div><div>}</div></div><div><br></div><div>Which is functionally equivalent (it actually generates a view dynamically with the same ruby code) to this:</div><div><br></div><div>pane :summary do</div><div> field :id</div><div> field :active, :is_active</div><div> field :full_name, :mario</div><div>end</div><div><br></div><div>field :foo</div><div><br></div><div>And this is how it could be used to generate the views from data:</div><div><br></div><div>render json: View.from_json(unparsed_json).<wbr>new(entity)</div><div>render json: View.from_yaml(unparsed_yaml).<wbr>new(entity)</div><div>render json: View.from_hash(data_as_hash).<wbr>new(entity)</div><div><br></div><div>Since those methods generate classes, they can be used to inherit new views, or even doing something like this:</div><div><br></div><div>class EAPServerView < View.from_json(:code_to_get_<wbr>from_hawkular)</div><div>end</div><div><br></div><div>Also, another important thing is that methods defined inside a view are used for the rendering, so attribute transformation can done in the view, instead of the entity if necessary, like this:</div><div><br></div><div>entity = OpenStruct.new(foo: :bar)</div><div>class MyView < View</div><div> field :foo</div><div><br></div><div> def foo</div><div> :baz</div><div> end</div><div>end</div><div><br></div><div>Then rendering it would return something like { "foo": "baz" }.</div><div><br></div><div>The changes are available on the same repo as always: <a href="http://github.com/cfcosta/dynamic-entity-poc" target="_blank">github.com/cfcosta/<wbr>dynamic-entity-poc</a> , and you can find examples on how this work on view_spec.rb, and examples of schemas on spec/fixtures/view_import.*</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Jul 18, 2017 at 9:42 AM, Heiko Rupp <span dir="ltr"><<a href="mailto:hrupp@redhat.com" target="_blank">hrupp@redhat.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 17 Jul 2017, at 15:59, Caina Costa wrote:<br>
<br>
> If we have a WildflyDomainControllerServer to render, first it will<br>
> try to find WildFlyDomainControllerServerV<wbr>iew, then<br>
<br>
</span><span>I (still) consider that a problem, even if better than what we have now.<br>
</span>I can't tell e.g. the Infinispan folks "Listen you know your stuff<br>
<span>better than we do, so please start writing Ruby code and create a<br>
pull-request against the hawkular-provider gem"<br>
<br>
My goal really is to externalise that as much as possible (in to the<br>
hawkular-server or agent side), so that it is<br>
possible for other groups to write the description in e.g. JSON for<br>
their UI and the relation between Entities.<br>
<br>
Having that in Hawkular/Agent also allows us to introduce new supported<br>
</span>stuff outside the release cycles of ManageIQ and their downstream<br>
CloudForms.<br>
I am not even sure if e.g. introducing support for Infinispan could be<br>
part of a z-Stream release, which is supposed to be bugfixes only.<br>
<span>So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release<br>
after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular<br>
side, we can update the Middleware Manager / agent and the support would<br>
show automagically.<br>
Of course we may at some point in time create more specific UIs for some<br>
task, but the 80% case should work without modification of MiQ code.<br>
<br>
</span>We need to generate the views dynamically, by fetching the (meta) data<br>
<span>and the schema and generating the view from that. That means we don't<br>
need to change anything on ui-classic to add new entity types.<br>
</span><span>Those *EntityView Ruby objects need to be created from data retrieved<br>
from the Hawkular side and not by checking in new code into the<br>
hawkular-provider gem when supporting new Entities.<br>
<br>
</span>The metadata should probably stored inside MiQ for faster access, but<br>
that is a 2ndary concern.<br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>