Open Stack

Hi Eric,

I have two questions:


1.       An alarm is usually raised on a resource, and in Vitrage we can send you the details of that resource. Is there a way in Congress for the alarm to reference a resource that exists in another table? And what if the resource does not exist in Congress?

2.       Do you plan to support also updateRows? This can be useful for alarm state changes.

Thanks,
Ifat


From: Eric K <ekcs.openstack at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Saturday, 6 January 2018 at 3:50
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [congress] generic push driver

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/20180107/940fed97/attachment.html>