Re: [wildfly-dev] Map / reduce for management operations

Am 31.10.2014 um 20:05 schrieb Brian Stansberry <brian.stansberry(a)redhat.com&gt;: > On 10/31/14, 1:30 PM, Heiko Braun wrote: > >> On 31 Oct 2014, at 18:07, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >> >> This would definitely be useful. >> >> On the server side we already support a wildcard variant of >> read-resource. But it only works within a single process, not across >> processes in the domain. We've never had time to sort that issue. I'd >> like to see this feature built on a foundation of a proper cross-domain >> wildcard read-resource. That will kill two birds with one stone, plus >> ensure consistent behavior. > > glad to hear. we specifically isolated it from the current codebase to explore the ideas, before merging with existing approaches. Bringing it into the main codebase would be a task for somebody with a better understanding of the management layer internals. Oh. I can't commit to when we'd be able to do multi-process wildcard read-resource. I was fired up by the possibility that a talented guy like Harald was interested. :) This thread certainly raises the visibility of it though. I'll be thinking about how to do it. > >> >> Any other ideas for a name for this? "Map / reduce" to me implies a much >> broader set of functionality, and I wouldn't want to falsely advertise, >> nor burn an operation name that we may want later. > > the name describes quiet well what's actually happening behind the scenes, but I agree that "map/reduce" is quiet overloaded these days and might lead to false expectations. > >> That also relates to >> Stan's point in his response, re: this being an element in a broader >> query feature. If it has a precise name that implies a narrow scope, if >> later on there is a broader feature that broader feature can co-exist >> with its ancestor. >> >>> On 10/31/14, 10:35 AM, Harald Pehl wrote: >>> TL;DR >>> >>> For management clients it is tedious and awkward to read resources / >>> attributes in big domains (e.g. return the state of all running servers >>> across all hosts which are part of server group "foo"). Today this >>> requires to setup multiple composite operations *on the client* which >>> need to be executed in a specific order. This proposal suggests a new >>> operation which collects all relevant information *on the >>> server* and returns only the relevant data in one go to the client. >>> >>> -------------------- >>> >>> # Background: >>> >>> In the admin console we often need to read specific attributes across a >>> domain or across a deeply nested resource: >>> >>> - List all enabled data sources of the current profile >>> - Show the port offset of all running servers across all hosts >>> - Get all users which belong to role Operator >>> >>> Even for small domains with two server groups and a small number of >>> servers this procedure is awkward and error prone. What makes it even >>> more difficult is the asynchronous nature of the admin console. Soon you >>> end up in a deeply nested callback-hell. Besides that these 'queries' >>> lead to poor performance for big domains with tens of groups, hosts and >>> servers. >>> >>> # Proposal / Prototype >>> >>> The GitHub repository at [1] contains a more detailed description of the >>> problem statement and a working prototype. This includes details such as >>> how to address the requested resources, how the information is retrieved >>> and how to handle errors. >>> >>> The proposal also includes a way to filter and reduce the resources >>> against a list of attributes and values *before* the response is sent to >>> the client. >>> >>> [1] https://github.com/hpehl/map-reduce >>> >>> --- >>> 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 >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat