Bug 563243

Summary: Request capability of using NOT and OR in Dynagroups expression language
Product: [Other] RHQ Project Reporter: dsteigne
Component: Core ServerAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 1.3.1CC: jshaughn, rrobinso, tao
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-27 18:37:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 565628    

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.