[openstack-dev] [congress] generic push driver

Tim Hinrichs tim at styra.com
Mon Jan 8 15:31:28 UTC 2018


It's probably worth considering PATCH instead of PUT for updating the table.

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

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/26b3e3bd/attachment.html>


More information about the OpenStack-dev mailing list