Open Stack

From:  Tim Hinrichs <tim at styra.com>
Date:  Monday, January 8, 2018 at 7:31 AM
To:  Eric Kao <ekcs.openstack at gmail.com>
Cc:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject:  Re: [congress] generic push driver

> It's probably worth considering PATCH instead of PUT for updating the table.
Ah right of course. PATCH makes more sense here.
> 
> http://restcookbook.com/HTTP%20Methods/patch/
> 
> You could also think about using JSON-patch to describe the requested update.
> It provides fine-grained update semantics:
> 
> https://tools.ietf.org/html/rfc6902
Hmm it would be very nice to follow an existing standard. Unfortunately the
json patch path specifications seem like an awkward fit with the set
semantics of congress tables. Removal, for example, must be done by
specifying the array index of the row to be removed. But perhaps we can
borrow the style of json patch for patching sets. For example:
PATCH '/v1/data-sources/vitrage/tables/alarms' with body:
[
  {
    "op":"add",
    "path":"/",
    "value":{
      "id":"1-1",
      "name":"name1",
      "state":"active",
      "severity":1
    }
  },
  {
    "op":"add",
    "path":"/",
    "value":[
      "1-2",
      "name2",
      "active",
      2
    ]
  },
  {
    "op":"remove",
    "path":"/",
    "value":[
      "1-2",
      "name2",
      "active",
      2
    ]
  }
]

Would that work well? At least there will be well-defined semantic based on
sequential operation.
> 
> Tim
> 
> On Fri, Jan 5, 2018 at 5:50 PM Eric K <ekcs.openstack at gmail.com> wrote:
>> We've been discussing generic push drivers for Congress for quite a while.
>> Finally sketching out something concrete and looking for some preliminary
>> feedback. Below are sample interactions with a proposed generic push driver.
>> A generic push driver could be used to receive push updates from vitrage,
>> monasca, and many other sources.
>> 
>> 1. creating a datasource:
>> 
>> congress datasource create generic_push_driver vitrage --config schema='
>> {
>>   "tables":[
>>     {
>>       "name":"alarms",
>>       "columns":[
>>         "id",
>>         "name",
>>         "state",
>>         "severity",
>>       ]
>>     }
>>   ]
>> }
>> '
>> 
>> 2. Update an entire table:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "rows":[
>>     {
>>       "id":"1-1",
>>       "name":"name1",
>>       "state":"active",
>>       "severity":1
>>     },
>>     [
>>       "1-2",
>>       "name2",
>>       "active",
>>       2
>>     ]
>>   ]
>> }
>> Note that a row can be either a {} or []
>> 
>> 
>> 3. perform differential update:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "addrows":[
>>     {
>>       "id":"1-1",
>>       "name":"name1",
>>       "state":"active",
>>       "severity":1
>>     },
>>     [
>>       "1-2",
>>       "name2",
>>       "active",
>>       2
>>     ]
>>   ]
>> }
>> 
>> OR
>> 
>> {
>>   "deleterows":[
>>     {
>>       "id":"1-1",
>>       "name":"name1",
>>       "state":"active",
>>       "severity":1
>>     },
>>     [
>>       "1-2",
>>       "name2",
>>       "active",
>>       2
>>     ]
>>   ]
>> }
>> 
>> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together
>> with some well defined semantics. Alternatively we may mandate that each
>> request can have only one of the three pieces.
>> 
>> Note 2: we leave it as the responsibility of the sender to send and confirm
>> the requests for differential updates in correct order. We could add
>> sequencing in future work.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180108/6db13d63/attachment.html>