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.openst...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Saturday, 6 January 2018 at 3:50
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
