Open Stack

Hi Ifat,
From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.afek at nokia.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Sunday, January 7, 2018 at 4:00 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [congress] generic push driver

> 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?

First, the columns I chose are just a minimal sample to illustrate the
generic nature of the driver. In use with vitrage, we would probably also
want to include columns such as `resource_id`. Does that address the need to
reference a resource? That resource referenced by ID may or may not exist in
another part of Congress. It would be the job of the policy to resolve
references when taking appropriate actions. If referential integrity is
needed, additional policy rules can be specified to catch breakage.

This brings up a related question I had about vitrage:
Looking at the vertex properties listed here:
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py
#L17

Where can I find more information about the type and content of data in each
property?

Exapmle:
- is the `resource` property an ID string or a python object reference?
- what does the property `is_real_vitrage_id` represent?
- what is the difference between `resource_id` and `vitrage_resource_id` ?

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

Are you thinking about updating an entire row or updating a specific field
of a row? That is, update
Row {"id":"1-1", "name":"name1", "state":"active", "severity":1} to become
{"id":"1-1", "name":"name1", "state":"active", "severity":100}
Vs
Update the severity field of row with id "1-1" to severity 100.
Both could be supported, but the second one is more complex to support
efficiently.

Thanks!
Eric
>  
> 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.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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