On 6 Feb 2017, at 11:15, Harald Pehl <hpehl(a)redhat.com&gt; wrote: TL;DR A tool to analyse the WildFly management model tree using a graph database. # Longer version As a heavy consumer of the WildFly management model I've always been looking for a way to analyse the management model. So I decided to start a little side project over the weekend. The result is a tool [1] which reads a (sub)tree of the WildFly management model and stores the results into a graph database using Neo4j [2]. To get started, you need a running WildFly and Neo4j instance. The tool writes nodes for each resource, attribute, operation, request property and capability. In addition it creates relationships between these nodes. You can use the data to - get alternatives and requires relations between attributes - get deprecated attributes and request parameters for one or all resources - find attributes which might miss a capability reference - find inconsistent attributes - see differences between resources (using external diff tools) See [3] for more use cases. I hope this is useful for others as well. Feedback, suggestions and critics are welcome! [1] https://github.com/hal/model-graph [2] https://neo4j.com/ [3] https://github.com/hal/model-graph#examples -- Harald Pehl JBoss by Red Hat http://hpehl.info _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

If this can do model comparison that could be very useful to double check no incompatible changes have leaked in without an appropriate version bump. On 06/02/17 13:14, Kabir Khan wrote: > > Very cool. If we could have the neo4j server somewhere central, perhaps we > could eventually do the comparisons of model versions from there? >> >> On 6 Feb 2017, at 11:15, Harald Pehl <hpehl(a)redhat.com&gt; wrote: >> >> TL;DR >> >> A tool to analyse the WildFly management model tree using a graph >> database. >> >> # Longer version >> >> As a heavy consumer of the WildFly management model I've always been >> looking for a way to analyse the management model. So I decided to >> start a little side project over the weekend. The result is a tool [1] >> which reads a (sub)tree of the WildFly management model and stores the >> results into a graph database using Neo4j [2]. To get started, you >> need a running WildFly and Neo4j instance. >> >> The tool writes nodes for each resource, attribute, operation, request >> property and capability. In addition it creates relationships between >> these nodes. You can use the data to >> >> - get alternatives and requires relations between attributes >> - get deprecated attributes and request parameters for one or all >> resources >> - find attributes which might miss a capability reference >> - find inconsistent attributes >> - see differences between resources (using external diff tools) >> >> See [3] for more use cases. I hope this is useful for others as well. >> Feedback, suggestions and critics are welcome! >> >> [1] https://github.com/hal/model-graph >> [2] https://neo4j.com/ >> [3] https://github.com/hal/model-graph#examples >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Good point. I guess this could easily be done by moving this to OpenShift. With dedicated WildFly / Neo4j instances for each major WildFly version. This way we could also provide an online Neo4j browser (similar to [1] and [2]). Even with a custom documentation and mini guides. [1] https://stackoverflow.com/questions/37370820/hosting-a- public-read-only-neo4j-instance-in-the-cloud [2] http://neo4j.het.io/browser/ On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan <kabir.khan(a)jboss.com&gt; wrote: > Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >> On 6 Feb 2017, at 11:15, Harald Pehl <hpehl(a)redhat.com&gt; wrote: >> >> TL;DR >> >> A tool to analyse the WildFly management model tree using a graph database. >> >> # Longer version >> >> As a heavy consumer of the WildFly management model I've always been >> looking for a way to analyse the management model. So I decided to >> start a little side project over the weekend. The result is a tool [1] >> which reads a (sub)tree of the WildFly management model and stores the >> results into a graph database using Neo4j [2]. To get started, you >> need a running WildFly and Neo4j instance. >> >> The tool writes nodes for each resource, attribute, operation, request >> property and capability. In addition it creates relationships between >> these nodes. You can use the data to >> >> - get alternatives and requires relations between attributes >> - get deprecated attributes and request parameters for one or all resources >> - find attributes which might miss a capability reference >> - find inconsistent attributes >> - see differences between resources (using external diff tools) >> >> See [3] for more use cases. I hope this is useful for others as well. >> Feedback, suggestions and critics are welcome! >> >> [1] https://github.com/hal/model-graph >> [2] https://neo4j.com/ >> [3] https://github.com/hal/model-graph#examples >> >> -- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Harald Pehl JBoss by Red Hat http://hpehl.info _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. Or version is a node and the relationship between versions are edges. Either way those relationships aren’t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don’t store the kind of version relationship data that would allow that to be worked out automatically. Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ‘required’ makes the default pointless). This would have saved me some time and probably still will as I’m sure I’ll have to redo the search to make sure I got it right. > On Feb 6, 2017, at 7:33 AM, Harald Pehl <hpehl(a)redhat.com&gt; wrote: > > Good point. I guess this could easily be done by moving this to > OpenShift. With dedicated WildFly / Neo4j instances for each major > WildFly version. This way we could also provide an online Neo4j > browser (similar to [1] and [2]). Even with a custom documentation and > mini guides. > > [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-n... > [2] http://neo4j.het.io/browser/ > > On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan <kabir.khan(a)jboss.com&gt; wrote: >> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>> On 6 Feb 2017, at 11:15, Harald Pehl <hpehl(a)redhat.com&gt; wrote: >>> >>> TL;DR >>> >>> A tool to analyse the WildFly management model tree using a graph database. >>> >>> # Longer version >>> >>> As a heavy consumer of the WildFly management model I've always been >>> looking for a way to analyse the management model. So I decided to >>> start a little side project over the weekend. The result is a tool [1] >>> which reads a (sub)tree of the WildFly management model and stores the >>> results into a graph database using Neo4j [2]. To get started, you >>> need a running WildFly and Neo4j instance. >>> >>> The tool writes nodes for each resource, attribute, operation, request >>> property and capability. In addition it creates relationships between >>> these nodes. You can use the data to >>> >>> - get alternatives and requires relations between attributes >>> - get deprecated attributes and request parameters for one or all resources >>> - find attributes which might miss a capability reference >>> - find inconsistent attributes >>> - see differences between resources (using external diff tools) >>> >>> See [3] for more use cases. I hope this is useful for others as well. >>> Feedback, suggestions and critics are welcome! >>> >>> [1] https://github.com/hal/model-graph >>> [2] https://neo4j.com/ >>> [3] https://github.com/hal/model-graph#examples >>> >>> -- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

With the help of Tomaz, I've managed to put the model-graph databases for the most recent WildFly versions online [1]. Have fun! [1] http://model-graph.ci.wildfly.org/ On Mon, Feb 6, 2017 at 6:20 PM, Harald Pehl <hpehl(a)redhat.com&gt; wrote: > Yeah I thought about versioning by reading the management model > version from the root resource and include this data to the graph > somehow. But versioning is not well supported in Neo4j, so I decided > to start w/o version support. > > On Mon, Feb 6, 2017 at 5:53 PM, Brian Stansberry > <brian.stansberry(a)redhat.com&gt; wrote: >> If version was an distinguishing property of a resource node then the relationship between versions becomes another edge. >> >> Or version is a node and the relationship between versions are edges. >> >> Either way those relationships aren’t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don’t store the kind of version relationship data that would allow that to be worked out automatically. >> >> Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ‘required’ makes the default pointless). This would have saved me some time and probably still will as I’m sure I’ll have to redo the search to make sure I got it right. >> >>> On Feb 6, 2017, at 7:33 AM, Harald Pehl <hpehl(a)redhat.com&gt; wrote: >>> >>> Good point. I guess this could easily be done by moving this to >>> OpenShift. With dedicated WildFly / Neo4j instances for each major >>> WildFly version. This way we could also provide an online Neo4j >>> browser (similar to [1] and [2]). Even with a custom documentation and >>> mini guides. >>> >>> [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-n... >>> [2] http://neo4j.het.io/browser/ >>> >>> On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan <kabir.khan(a)jboss.com&gt; wrote: >>>> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there? >>>>> On 6 Feb 2017, at 11:15, Harald Pehl <hpehl(a)redhat.com&gt; wrote: >>>>> >>>>> TL;DR >>>>> >>>>> A tool to analyse the WildFly management model tree using a graph database. >>>>> >>>>> # Longer version >>>>> >>>>> As a heavy consumer of the WildFly management model I've always been >>>>> looking for a way to analyse the management model. So I decided to >>>>> start a little side project over the weekend. The result is a tool [1] >>>>> which reads a (sub)tree of the WildFly management model and stores the >>>>> results into a graph database using Neo4j [2]. To get started, you >>>>> need a running WildFly and Neo4j instance. >>>>> >>>>> The tool writes nodes for each resource, attribute, operation, request >>>>> property and capability. In addition it creates relationships between >>>>> these nodes. You can use the data to >>>>> >>>>> - get alternatives and requires relations between attributes >>>>> - get deprecated attributes and request parameters for one or all resources >>>>> - find attributes which might miss a capability reference >>>>> - find inconsistent attributes >>>>> - see differences between resources (using external diff tools) >>>>> >>>>> See [3] for more use cases. I hope this is useful for others as well. >>>>> Feedback, suggestions and critics are welcome! >>>>> >>>>> [1] https://github.com/hal/model-graph >>>>> [2] https://neo4j.com/ >>>>> [3] https://github.com/hal/model-graph#examples >>>>> >>>>> -- >>>>> Harald Pehl >>>>> JBoss by Red Hat >>>>> http://hpehl.info >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> >>> -- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> > > > > -- > Harald Pehl > JBoss by Red Hat > http://hpehl.info -- Harald Pehl JBoss by Red Hat http://hpehl.info