Format of the query to update groups via API is not documented
In the API documentation, the "query" for groups update (see http://www.rudder-project.org/rudder-api-doc/#api-Groups-createGroup) is not documented.
#1 Updated by François ARMAND almost 4 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
"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:
"comparator": the kind of comparator to use:
exits / notExists: only check the presence of that kind of attribute for the object in the node
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
There is example in the tests for query:
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.