Project

General

Custom queries

Profile

Actions

Bug #6221

closed

Format of the query to update groups via API is not documented

Added by François ARMAND about 10 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
1 (highest)
Category:
Documentation
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

In the API documentation, the "query" for groups update (see http://www.rudder-project.org/rudder-api-doc/#api-Groups-createGroup) is not documented.


Related issues 1 (0 open1 closed)

Has duplicate Rudder - User story #10299: API Doc missing possibilities of New Group's query syntaxResolvedActions
Actions #1

Updated by François ARMAND about 10 years ago

  • Description updated (diff)

The json structure is organized like that:

"select" : mandatory value,  "node" or "nodeAndPolicyServer" 
"composition": either "and" or "or". Optionnal, default to "and"
"where": an array of json objects composed of:
"objectType": the kind of object to look for. They are all defined in https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/main/scala/com/normation/rudder/domain/queries/DitQueryData.scala around line #280 (def objectTypes = Map... ). Some interesting ones:
node : for all the OS, RAM, etc
environmentVariable
software
"attribute": the name of the attribute to lookup for the given object. The possible names are defined in DitQueryData to: it's the huge list of "ObjectCriterion". Problem: most use name defined elsewhere in the form of "A_OS_VERSION" etc. The name are defined in one the two files:
https://github.com/Normation/ldap-inventory/blob/branches/rudder/3.0/inventory-repository/src/main/scala/com/normation/inventory/ldap/core/LDAPConstants.scala
https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/main/scala/com/normation/rudder/domain/RudderLDAPConstants.scala
"comparator": the kind of comparator to use:
exits / notExists: only check the presence of that kind of attribute for the object in the node
eq: equals
notEq: not equals
gt / gteq: greater than / greater or equals
lt / lteq : lesser than / lesser or equals
regex: match the given pattern. The authorized regex are the Java one, as defined in http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
notRegex : all entries not matching the given regex
and there is a special syntax for key=value objects, like "environmentVariable". For them, you use the attribute "name.value", the comparator to use, with a new one:
hasKey: to only check for the key part equals the given value
else, the comparison is done on "key=value", and you can do almost anything with regex
Ex: {"select":"nodeAndPolicyServer","composition":"And","where":[{"objectType":"environmentVariable","attribute":"name.value","comparator":"regex","value":".*NAME=r[o]{2}t"}]}

There is example in the tests for query:
https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/test/scala/com/normation/rudder/services/queries/TestJsonQueryLexing.scala
https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/test/scala/com/normation/rudder/services/queries/TestQueryProcessor.scala

So, if you read until hear, you now see that the current format is quite ad-hoc - or more preciselly, it reflects far to much the underlying storage format.
A more versatile version is think about, based on the JSON format of the node details returned by the API and a XPATH kind of query. But well, it's not for now, and the current language is already in the nature, so it will be supported :)
At least, in 3.1 we are going to try to normalize object and attribute names so that they match the names in the node details returned by the API.

Actions #29

Updated by Alexis Mousset about 8 years ago

  • Status changed from In progress to Rejected

Duplicate of #10299.

Actions

Also available in: Atom PDF