Feature: Add KV "entry" actions

[cognifloyd]

An "entry" is a JSON object with properties. Multiple entries are stored under a JSON serialized object (as created by st2.kv.set_object) in the datastore. When you retrieve an "entry", you can specify a fallback "entry" to use for defaults.

For example, consider this object:

{
  "myentry": {
    "prop_a": "overriden"
  },
  "default": {
    "prop_a": "A",
    "prop_b": "B",
    "prop_c": "C"
  }
}

If you retrieve myentry with the default fallback, you would get this object:

{
  "prop_a": "overriden",
  "prop_b": "B",
  "prop_c": "C"
}

These are the new actions:

• kv.entry.get - Retrieve entry in a JSON serialized object from the datastore. An entry is a standard JSON object with properties.
• kv.entry.set_property - Update or insert a property in the named entry of a JSON serialized object. Then, serialize and store the updated object. The property's value may be any json-serializable type.
• kv.entry.append_property - Add the value to the end of an array property in the named entry of a JSON serialized object. Then, serialize and store the updated object. The property must be an array. The value to append can be anything.
• kv.entry.delete_property - Delete a property from a named entry of a JSON serialized object in the datastore. If the entry is empty, delete it as well.

Since more than one action could edit the same KV object at the same time, the edit actions (set_property, append_property, and delete_property) all use a distributed lock through the coordination backend (if configured) to serialize edits.

My use-case: I am using this as to provide environment specific config in the datastore. So, I have something like these entries: default (the fallback), prod, stage, qa, dev. Then various actions or workflows just need to get the entry for the environment they're working with, and not have to worry about selecting from a different default object if it a var is undefined for that environment (The YAQL for selecting from multiple objects like that gets really ugly really fast).

This pattern of config with defaults seems common, so am submitting this as part of the st2 pack to make the datastore an even more useful tool with less effort.

[amanda11]

Just curious - why "upsert_property" instead of just "set_property" - I think a set would be normally considered an add or update if exists function.

[cognifloyd]

set_property would be more consistent with the others. My original reasons for selecting upsert instead of set don't apply now because I refactored before submitting the PR :P Before I had upsert_entry_property (instead of entry.upsert_property) - trying to indicate that it was being inserted or updated within the entry.

I think I'll just rename it to set for consistency :)

[cognifloyd]

Updated to use set instead of upsert.

[CLAassistant]

All committers have signed the CLA.