This feature would provide the ability to build a recursive group which excludes child resources that do not match specific criteria. For example, a group of platforms which include specific child resource types and excludes some resource if their name does not contain a predetermined value. Creating groups in this fashion is necessary to logically group resources based on their application or use for group management and role assignment. Take for example, JBoss EAP resources are assigned to an application group and roles are defined which represent permissions within that application group. The application group should be made up of the EAP resources which are assigned to it and those EAP resource's parent platforms and select child types of those platforms. The end result is that the platform and select platform child resources along with specific EAP servers would be placed into a group based on criteria that matched the EAP resource. This greatly simplifies the management of the roles and reduces the need for multiple resource groups to represent the application content. By simplifying the management of these roles and groups, the risk of user error is reduced as the group's criteria is contained in a single definition instead of requiring multiple places and views to be updated if criteria changes. The following describes the user's use-case and provides some details on the end result: For this example, the following inventory tree will be used. Although there may be many more platforms, servers, services, and other resource types in inventory, this tree is only meant to depict the resources and types that we are focusing on for this example. . `-- Platforms |-- dev-01 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | |-- EAP dev-01:1099 app01 | | `... | `-- EAP dev-01:1199 app02 | `... |-- dev-02 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | |-- EAP dev-02:1099 app01 | | `... | `-- EAP dev-02:1199 app02 | `... |-- uat-01 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | |-- EAP uat-01:1099 app01 | | `... | `-- EAP uat-01:1199 app02 | `... `-- uat-02 |-- CPUs | |-- CPU 0 | |-- CPU 1 | |-- CPU 2 | `-- CPU 3 |-- File Systems | |-- / | |-- /boot | |-- /dev/shm | `-- /tmp |-- Network Adapters | |-- eth0 | |-- eth1 | `-- lo `-- JBoss AS Servers |-- EAP uat-02:1099 app01 | `... `-- EAP uat-02:1199 app02 `... From the above inventory, EAP servers get allocated to an application group. For this example, there will be two application groups as follows: . |-- Application Group 01 | |-- EAP dev-01:1099 app01 | |-- EAP dev-02:1099 app01 | |-- EAP uat-01:1099 app01 | `-- EAP uat-02:1099 app01 `-- Application Group 02 |-- EAP dev-01:1099 app02 |-- EAP dev-02:1099 app02 |-- EAP uat-01:1099 app02 `-- EAP uat-02:1099 app02 The purpose of this separation is for roles/permission settings. Each group gets a role added to it which represents the permissions a user with that role should have within the application group. Ideally, users in this example will either have read or read/write permissions to either Application Group 01 or Application Group 02 but most likely not both. Assuming the application groups are recursive, the user will have the ability to manage or view each EAP server that represents their responsible application along with its child services such as deployments, datasources, JVMs, etc. The existing limitation with group definition and management seems to be with the next requirement. Not only should the application group users be confined to their respective applications but they should also have the ability to view or manage parent level resources above the EAP server and certain siblings. Specifically, the platforms (parent of the EAP servers that are in the application group) and the platform's CPUs, file systems, and network adapters. The resulting application group should look something like: . |-- Application Group 01 | `-- Platforms | |-- dev-01 | | |-- CPUs | | | |-- CPU 0 | | | |-- CPU 1 | | | |-- CPU 2 | | | `-- CPU 3 | | |-- File Systems | | | |-- / | | | |-- /boot | | | |-- /dev/shm | | | `-- /tmp | | |-- Network Adapters | | | |-- eth0 | | | |-- eth1 | | | `-- lo | | `-- JBoss AS Servers | | `-- EAP dev-01:1099 app01 | | `... | |-- dev-02 | | |-- CPUs | | | |-- CPU 0 | | | |-- CPU 1 | | | |-- CPU 2 | | | `-- CPU 3 | | |-- File Systems | | | |-- / | | | |-- /boot | | | |-- /dev/shm | | | `-- /tmp | | |-- Network Adapters | | | |-- eth0 | | | |-- eth1 | | | `-- lo | | `-- JBoss AS Servers | | `-- EAP dev-02:1099 app01 | | `... | |-- uat-01 | | |-- CPUs | | | |-- CPU 0 | | | |-- CPU 1 | | | |-- CPU 2 | | | `-- CPU 3 | | |-- File Systems | | | |-- / | | | |-- /boot | | | |-- /dev/shm | | | `-- /tmp | | |-- Network Adapters | | | |-- eth0 | | | |-- eth1 | | | `-- lo | | `-- JBoss AS Servers | | `-- EAP uat-01:1099 app01 | | `... | `-- uat-02 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | `-- EAP uat-02:1099 app01 | `... `-- Application Group 02 `-- Platforms |-- dev-01 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | `-- EAP dev-01:1199 app02 | `... |-- dev-02 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | `-- EAP dev-02:1199 app02 | `... |-- uat-01 | |-- CPUs | | |-- CPU 0 | | |-- CPU 1 | | |-- CPU 2 | | `-- CPU 3 | |-- File Systems | | |-- / | | |-- /boot | | |-- /dev/shm | | `-- /tmp | |-- Network Adapters | | |-- eth0 | | |-- eth1 | | `-- lo | `-- JBoss AS Servers | `-- EAP uat-01:1199 app02 | `... `-- uat-02 |-- CPUs | |-- CPU 0 | |-- CPU 1 | |-- CPU 2 | `-- CPU 3 |-- File Systems | |-- / | |-- /boot | |-- /dev/shm | `-- /tmp |-- Network Adapters | |-- eth0 | |-- eth1 | `-- lo `-- JBoss AS Servers `-- EAP uat-02:1199 app02 `... The end result is that both Application Group 01 and Application Group 02 contain the same platform, platform CPU, platform file system, and platform network adapter members. But they contain different EAP server members. The fact that the two groups contain the same platform level resources is only a coincident driven by the fact that all the platforms in this example contain the specific EAP servers that qualify it to appear in the application group. So a pseudo query/criteria to build the group membership might look like: Application Group 01 = ( (All Platforms, that contain a child JBoss AS Server who's name ENDS WITH 'app01') AND (Its Child CPUs) AND (Its Child File Systmes) AND (Its Child Network Adapters) AND (Its Child JBoss AS Servers who's name ENDS WITH 'app01') ) Application Group 02 = ( (All Platforms, that contain a child JBoss AS Server who's name ENDS WITH 'app02') AND (Its Child CPUs) AND (Its Child File Systmes) AND (Its Child Network Adapters) AND (Its Child JBoss AS Servers who's name ENDS WITH 'app02') +++ This bug was initially created as a clone of Product RFE Bug #850460 +++ --- Additional comment from jshaughn on 2012-08-21 14:55:18 EDT --- After an initial investigation I'd say this enhancement is feasible although not straightforward. The idea, I gather, is to be able to define a recursive group that allows for Includes and Excludes capabilities. Those would likely be a list of expressions like: [1] plugin [2] plugin|type [3] plugin|type|name Include or Exclude: [1] All implicit resources for types in the specified plugin. [2] All implicit resources for the resource type. [3] All implicit resources for resources of the type and matching the name (likely allowing simple wildcards, or possibly exact vs substring) If Includes are specified then all candidates must match an Includes condition. Excludes applies only after Includes filtering. Although possibly verbose, this would allow for the needs in the presented example (in PRODMGT-221). As for performance, the filtering would certainly slow things down. Today we do all of the implicit resource mapping in db queries. Although not fast, it's all done db-side, and avoids any fetching of resources. (It does use recursive querying, thus limiting to 7-deep hierarchies, like other places in the system). We likely want to leave that intact because any other approach could introduce the need to pull information on potentially [tens of] thousands of resources. We'd likely build up the implicit mappings just like today, and then optionally apply subsequent, probably generated, filtering queries. We'd want to allow for the inclusion patterns whenever defining a group. For single group creation or as part of a dynaGroup definition. This would require: - additions to the DB schema for storing the patterns. - CRUD support - GUI support - additions to the [remote] API - the actual filtering support This would have no effect on non-recursive groups. Rough estimate: 3 man weeks One other tricky point that I'm not sure about is the impact on the resource group tree in the GUI. It is likely a non-issue but there is perhaps some possibility for implications in that area.