Bug 563243 - Request capability of using NOT and OR in Dynagroups expression language
Summary: Request capability of using NOT and OR in Dynagroups expression language
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 1.3.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: rhq_triage
TreeView+ depends on / blocked
 
Reported: 2010-02-09 16:28 UTC by dsteigne
Modified: 2018-10-27 16:15 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-05-27 18:37:47 UTC
Embargoed:


Attachments (Terms of Use)

Description dsteigne 2010-02-09 16:28:19 UTC
Description of problem:
Request capability of using AND & OR in Dynagroups expression language

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 dsteigne 2010-02-10 16:26:37 UTC
Correction, make that NOT and OR in Dynagroups expression.

(In reply to comment #0)
> Description of problem:
> Request capability of using AND & OR in Dynagroups expression language
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

Comment 2 wes hayutin 2010-02-16 16:56:35 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 3 wes hayutin 2010-02-16 17:01:44 UTC
making sure we're not missing any bugs in rhq_triage

Comment 4 Charles Crouch 2012-07-06 15:37:58 UTC
The need for this maybe reduced if Bug 832398 is implemented. If 832398 was supported then one could great a handcrafted group containing just the resources you wanted  (instead of OR'ing together a bunch of platform names) then you could use this group as the root for another dynagroup. Not a perfect match, but may be sufficient.

Comment 5 Jay Shaughnessy 2014-05-27 18:37:47 UTC
The 'memberof' expression may be sufficient. closing on assumption that this is sufficient.

Comment 6 Richard Robinson 2016-10-11 23:06:18 UTC
I'm wondering if we can re-open this feature request. I'm not sure that 'memberof' is sufficient for the use case of filtering out members of another ('parent') dynagroup; in short, the need for a NOT operator.

I've got a dynagroup that looks like this:

   resource.type.plugin = JBossAS7
   resource.version.contains = 6.4
   resource.type.category = SERVER
   resource.parent.type.category = PLATFORM
   groupby resource.pluginConfiguration[productType]

It works, it includes all the JBoss 6.4.x servers, but it also includes the JBoss 6.4.8 servers that are part of JON 3.3 -- which we won't want as part of the group. Not sure how I can do that using 'memberof', without the NOT operator.

Adding a tag to the parent platform (as suggested here https://access.redhat.com/solutions/25394) is not an option in this case. There could be hundreds of inventoried JBoss 6.4 servers, but just 1 or 2 JON servers (with their JBoss 6.4.8). It would be easier to just weed out the 1 or 2 (if ha) JON servers by a NOT operator than to rewrite the parent platform name of potentially hundreds of JBoss 6.4 servers.


Note You need to log in before you can comment on or make changes to this bug.