Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Won]

Hi,

I checked that both of the methods you propose work well.
After I add 'should_delete_outdated_entities' function to InstanceDriver,
it took about 10 minutes to clear the old Instance.
And I added two sentences you said to Nova-cpu.conf, so the vitrage
collector get notifications well.

Thank you for your help.

Best regards,
Won

2018년 11월 22일 (목) 오후 9:35, Ifat Afek 님이 작성:

> Hi,
>
> A deleted instance should be removed from Vitrage in one of two ways:
> 1. By reacting to a notification from Nova
> 2. If no notification is received, then after a while the instance vertex
> in Vitrage is considered "outdated" and is deleted
>
> Regarding #1, it is clear from your logs that you don't get notifications
> from Nova on the second compute.
> Do you have on one of your nodes, in addition to nova.conf, also a
> nova-cpu.conf? if so, please make the same change in this file:
>
> notification_topics = notifications,vitrage_notifications
>
> notification_driver = messagingv2
>
> And please make sure to restart nova compute service on that node.
>
> Regarding #2, as a second-best solution, the instances should be deleted
> from the graph after not being updated for a while.
> I realized that we have a bug in this area and I will push a fix to gerrit
> later today. In the meantime, you can add to
> InstanceDriver class the following function:
>
> @staticmethod
> def should_delete_outdated_entities():
> return True
>
> Let me know if it solved your problem,
> Ifat
>
>
> On Wed, Nov 21, 2018 at 1:50 PM Won  wrote:
>
>> I attached four log files.
>> I collected the logs from about 17:14 to 17:42. I created an instance of
>> 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed
>> the dentesting3 and vitrage colletor and graph logs are appeared.
>> When creating an instance in ubuntu server, it appears immediately in the
>> entity graph and logs, but when creating an instance in computer1 (multi
>> node), it appears about 5~10 minutes later.
>> I deleted an instance of 'deltesting3' around 17:26.
>>
>>
>>> After ~20minutes, there was only Apigateway. Does it make sense? did you
>>> delete the instances on ubuntu, in addition to deltesting?
>>>
>>
>> I only deleted 'deltesting'. After that, only the logs from 'apigateway'
>> and 'kube-master' were collected. But other instances were working well. I
>> don't know why only two instances are collected in the log.
>> NOV 19 In this log, 'agigateway' and 'kube-master' were continuously
>> collected in a short period of time, but other instances were sometimes
>> collected in long periods.
>>
>> In any case, I would expect to see the instances deleted from the graph
>>> at this stage, since they were not returned by get_all.
>>> Can you please send me the log of vitrage-graph at the same time (Nov
>>> 15, 16:35-17:10)?
>>>
>>
>> Information  'deldtesting3' that has already been deleted continues to be
>> collected in vitrage-graph.service.
>>
>> __
> 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
>
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

A deleted instance should be removed from Vitrage in one of two ways:
1. By reacting to a notification from Nova
2. If no notification is received, then after a while the instance vertex
in Vitrage is considered "outdated" and is deleted

Regarding #1, it is clear from your logs that you don't get notifications
from Nova on the second compute.
Do you have on one of your nodes, in addition to nova.conf, also a
nova-cpu.conf? if so, please make the same change in this file:

notification_topics = notifications,vitrage_notifications

notification_driver = messagingv2

And please make sure to restart nova compute service on that node.

Regarding #2, as a second-best solution, the instances should be deleted
from the graph after not being updated for a while.
I realized that we have a bug in this area and I will push a fix to gerrit
later today. In the meantime, you can add to
InstanceDriver class the following function:

@staticmethod
def should_delete_outdated_entities():
return True

Let me know if it solved your problem,
Ifat


On Wed, Nov 21, 2018 at 1:50 PM Won  wrote:

> I attached four log files.
> I collected the logs from about 17:14 to 17:42. I created an instance of
> 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed
> the dentesting3 and vitrage colletor and graph logs are appeared.
> When creating an instance in ubuntu server, it appears immediately in the
> entity graph and logs, but when creating an instance in computer1 (multi
> node), it appears about 5~10 minutes later.
> I deleted an instance of 'deltesting3' around 17:26.
>
>
>> After ~20minutes, there was only Apigateway. Does it make sense? did you
>> delete the instances on ubuntu, in addition to deltesting?
>>
>
> I only deleted 'deltesting'. After that, only the logs from 'apigateway'
> and 'kube-master' were collected. But other instances were working well. I
> don't know why only two instances are collected in the log.
> NOV 19 In this log, 'agigateway' and 'kube-master' were continuously
> collected in a short period of time, but other instances were sometimes
> collected in long periods.
>
> In any case, I would expect to see the instances deleted from the graph at
>> this stage, since they were not returned by get_all.
>> Can you please send me the log of vitrage-graph at the same time (Nov 15,
>> 16:35-17:10)?
>>
>
> Information  'deldtesting3' that has already been deleted continues to be
> collected in vitrage-graph.service.
>
>
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

On Thu, Nov 15, 2018 at 10:28 AM Won  wrote:

> Looking at the logs, I see two issues:
>> 1. On ubuntu server, you get a notification about the vm deletion, while
>> on compute1 you don't get it.
>> Please make sure that Nova sends notifications to 'vitrage_notifications'
>> - it should be configured in /etc/nova/nova.conf.
>> 2. Once in 10 minutes (by default) nova.instance datasource queries all
>> instances. The deleted vm is supposed to be deleted in Vitrage at this
>> stage, even if the notification was lost.
>> Please check in your collector log for the a message of "novaclient.v2.client
>> [-] RESP BODY" before and after the deletion, and send me its content.
>
>
>  I attached two log files. I created a VM in computer1 which is a computer
> node and deleted it a few minutes later. Log for 30 minutes from VM
> creation.
> The first is the log of the vitrage-collect that grep instance name.
> The second is the noovaclient.v2.clinet [-] RESP BODY log.
> After I deleted the VM, no log of the instance appeared in the collector
> log no matter how long I waited.
>
> I added the following to Nova.conf on the computer1 node.(attached file
> 'compute_node_local_conf.txt')
> notification_topics = notifications,vitrage_notifications
> notification_driver = messagingv2
> vif_plugging_timeout = 300
> notify_on_state_change = vm_and_task_state
> instance_usage_audit_period = hour
> instance_usage_audit = True
>

Hi,

>From the collector log RESP BODY messages I understand that in the
beginning there were the following servers:
compute1: deltesting
ubuntu: Apigateway, KubeMaster and others

After ~20minutes, there was only Apigateway. Does it make sense? did you
delete the instances on ubuntu, in addition to deltesting?
In any case, I would expect to see the instances deleted from the graph at
this stage, since they were not returned by get_all.
Can you please send me the log of vitrage-graph at the same time (Nov 15,
16:35-17:10)?

There is still the question of why we don't see a notification from Nova,
but let's try to solve the issues one by one.

Thanks,
Ifat
__
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

[openstack-dev] [vitrage] No IRC meeting this week

[Ifat Afek]

Hi,

We will not hold the Vitrage IRC meeting tomorrow, since some of our
contributors are in Berlin.
Our next meeting will be Next Wednesday, November 21th.

Thanks,
Ifat.
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

We solved the timestamp bug. There are two patches for master [1] and
stable/rocky [2].
I'll check the other issues next week.

Regards,
Ifat

[1] https://review.openstack.org/#/c/616468/
[2] https://review.openstack.org/#/c/616469/


On Wed, Oct 31, 2018 at 10:59 AM Won  wrote:

>
 [image: image.png]
 The time stamp is recorded well in log(vitrage-graph,collect etc), but
 in vitrage-dashboard it is marked 2001-01-01.
 However, it seems that the time stamp is recognized well internally
 because the alarm can be resolved and is recorded well in log.

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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

On Wed, Oct 31, 2018 at 11:00 AM Won  wrote:

> Hi,
>
>>
>> This is strange. I would expect your original definition to work as well,
>> since the alarm key in Vitrage is defined by a combination of the alert
>> name and the instance. We will check it again.
>> BTW,  we solved a different bug related to Prometheus alarms not being
>> cleared [1]. Could it be related?
>>
>
> Using the original definition, no matter how different the instances are,
> the alarm names are recognized as the same alarm in vitrage.
> And I tried to install the rocky version and the master version on the new
> server and retest but the problem was not solved. The latest bugfix seems
> irrelevant.
>

Ok. We will check this issue. For now your workaround is ok, right?


> Does the wrong timestamp appear if you run 'vitrage alarm list' cli
>> command? please try running 'vitrage alarm list --debug' and send me the
>> output.
>>
>
> I have attached 'vitrage-alarm-list.txt.'
>

I believe that you attached the wrong file. It seems like another log of
vitrage-graph.


>
>
>> Please send me vitrage-collector.log and vitrage-graph.log from the time
>> that the problematic vm was created and deleted. Please also create and
>> delete a vm on your 'ubuntu' server, so I can check the differences in the
>> log.
>>
>
> I have attached 'vitrage_log_on_compute1.zip' and
> 'vitrage_log_on_ubuntu.zip' files.
> When creating a vm on computer1, a vitrage-collect log occurred, but no
> log occurred when it was removed.
>

Looking at the logs, I see two issues:
1. On ubuntu server, you get a notification about the vm deletion, while on
compute1 you don't get it.
Please make sure that Nova sends notifications to 'vitrage_notifications' -
it should be configured in /etc/nova/nova.conf.

2. Once in 10 minutes (by default) nova.instance datasource queries all
instances. The deleted vm is supposed to be deleted in Vitrage at this
stage, even if the notification was lost.
Please check in your collector log for the a message of "novaclient.v2.client
[-] RESP BODY" before and after the deletion, and send me its content.

Br,
Ifat
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Won]

Hi,

>
> This is strange. I would expect your original definition to work as well,
> since the alarm key in Vitrage is defined by a combination of the alert
> name and the instance. We will check it again.
> BTW,  we solved a different bug related to Prometheus alarms not being
> cleared [1]. Could it be related?
>

Using the original definition, no matter how different the instances are,
the alarm names are recognized as the same alarm in vitrage.
And I tried to install the rocky version and the master version on the new
server and retest but the problem was not solved. The latest bugfix seems
irrelevant.

Does the wrong timestamp appear if you run 'vitrage alarm list' cli
> command? please try running 'vitrage alarm list --debug' and send me the
> output.
>

I have attached 'vitrage-alarm-list.txt.'


> Please send me vitrage-collector.log and vitrage-graph.log from the time
> that the problematic vm was created and deleted. Please also create and
> delete a vm on your 'ubuntu' server, so I can check the differences in the
> log.
>

I have attached 'vitrage_log_on_compute1.zip' and
'vitrage_log_on_ubuntu.zip' files.
When creating a vm on computer1, a vitrage-collect log occurred, but no log
occurred when it was removed.

Br,
Won



2018년 10월 30일 (화) 오전 1:28, Ifat Afek 님이 작성:

> Hi,
>
> On Fri, Oct 26, 2018 at 10:34 AM Won  wrote:
>
>>
>> I solved the problem of not updating the Prometheus alarm.
>> Alarms with the same Prometheus alarm name are recognized as the same
>> alarm in vitrage.
>>
>> --- alert.rules.yml
>> groups:
>> - name: alert.rules
>>   rules:
>>   - alert: InstanceDown
>> expr: up == 0
>> for: 60s
>> labels:
>>   severity: warning
>> annotations:
>>   description: '{{ $labels.instance }} of job {{ $labels.job }} has
>> been down
>> for more than 30 seconds.'
>>   summary: Instance {{ $labels.instance }} down
>> --
>> This is the contents of the alert.rules.yml file before I modify it.
>> This is a yml file that generates an alarm when the cardvisor
>> stops(instance down). Alarm is triggered depending on which instance is
>> down, but all alarms have the same name as 'instance down'. Vitrage
>> recognizes all of these alarms as the same alarm. Thus, until all 'instance
>> down' alarms were cleared, the 'instance down' alarm was recognized as
>> unresolved and the alarm was not extinguished.
>>
>
> This is strange. I would expect your original definition to work as well,
> since the alarm key in Vitrage is defined by a combination of the alert
> name and the instance. We will check it again.
> BTW,  we solved a different bug related to Prometheus alarms not being
> cleared [1]. Could it be related?
>
>
>> Can you please show me where you saw the 2001 timestamp? I didn't find it
>>> in the log.
>>>
>>
>> [image: image.png]
>> The time stamp is recorded well in log(vitrage-graph,collect etc), but in
>> vitrage-dashboard it is marked 2001-01-01.
>> However, it seems that the time stamp is recognized well internally
>> because the alarm can be resolved and is recorded well in log.
>>
>
> Does the wrong timestamp appear if you run 'vitrage alarm list' cli
> command? please try running 'vitrage alarm list --debug' and send me the
> output.
>
>
>> [image: image.png]
>> Host name ubuntu is my main server. I install openstack all in one in
>> this server and i install compute node in host name compute1.
>> When i create a new vm in nova(compute1) it immediately appear in the
>> entity graph. But in does not disappear in the entity graph when i delete
>> the vm. No matter how long i wait, it doesn't disappear.
>> Afther i execute 'vitrage-purge-data' command and reboot the
>> Openstack(execute reboot command in openstack server(host name ubuntu)), it
>> disappear. Only execute 'vitrage-purge-data' does not work. It need a
>> reboot to disappear.
>> When i create a new vm in nova(ubuntu) there is no problem.
>>
> Please send me vitrage-collector.log and vitrage-graph.log from the time
> that the problematic vm was created and deleted. Please also create and
> delete a vm on your 'ubuntu' server, so I can check the differences in the
> log.
>
> I implemented the web service of the micro service architecture and
>> applied the RCA. Attached file picture shows the structure of the web
>> service I have implemented. I wonder what data I receive and what can i do
>> when I link vitrage with kubernetes.
>> As i know, the vitrage graph does not present information about
>> containers or pods inside the vm. If that is correct, I would like to make
>> the information of the pod level appear on the entity graph.
>>
>> I follow (
>> https://docs.openstack.org/vitrage/latest/contributor/k8s_datasource.html)
>> this step. I attached the vitage.conf file and the kubeconfig file. The
>> contents of the Kubeconconfig file are copied from the contents of the
>> admin.conf file on the master node.
>> I want to check my settings are right and connected, but I don't know
>> 

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

On Fri, Oct 26, 2018 at 10:34 AM Won  wrote:

>
> I solved the problem of not updating the Prometheus alarm.
> Alarms with the same Prometheus alarm name are recognized as the same
> alarm in vitrage.
>
> --- alert.rules.yml
> groups:
> - name: alert.rules
>   rules:
>   - alert: InstanceDown
> expr: up == 0
> for: 60s
> labels:
>   severity: warning
> annotations:
>   description: '{{ $labels.instance }} of job {{ $labels.job }} has
> been down
> for more than 30 seconds.'
>   summary: Instance {{ $labels.instance }} down
> --
> This is the contents of the alert.rules.yml file before I modify it.
> This is a yml file that generates an alarm when the cardvisor
> stops(instance down). Alarm is triggered depending on which instance is
> down, but all alarms have the same name as 'instance down'. Vitrage
> recognizes all of these alarms as the same alarm. Thus, until all 'instance
> down' alarms were cleared, the 'instance down' alarm was recognized as
> unresolved and the alarm was not extinguished.
>

This is strange. I would expect your original definition to work as well,
since the alarm key in Vitrage is defined by a combination of the alert
name and the instance. We will check it again.
BTW,  we solved a different bug related to Prometheus alarms not being
cleared [1]. Could it be related?


> Can you please show me where you saw the 2001 timestamp? I didn't find it
>> in the log.
>>
>
> [image: image.png]
> The time stamp is recorded well in log(vitrage-graph,collect etc), but in
> vitrage-dashboard it is marked 2001-01-01.
> However, it seems that the time stamp is recognized well internally
> because the alarm can be resolved and is recorded well in log.
>

Does the wrong timestamp appear if you run 'vitrage alarm list' cli
command? please try running 'vitrage alarm list --debug' and send me the
output.


> [image: image.png]
> Host name ubuntu is my main server. I install openstack all in one in this
> server and i install compute node in host name compute1.
> When i create a new vm in nova(compute1) it immediately appear in the
> entity graph. But in does not disappear in the entity graph when i delete
> the vm. No matter how long i wait, it doesn't disappear.
> Afther i execute 'vitrage-purge-data' command and reboot the
> Openstack(execute reboot command in openstack server(host name ubuntu)), it
> disappear. Only execute 'vitrage-purge-data' does not work. It need a
> reboot to disappear.
> When i create a new vm in nova(ubuntu) there is no problem.
>
Please send me vitrage-collector.log and vitrage-graph.log from the time
that the problematic vm was created and deleted. Please also create and
delete a vm on your 'ubuntu' server, so I can check the differences in the
log.

I implemented the web service of the micro service architecture and applied
> the RCA. Attached file picture shows the structure of the web service I
> have implemented. I wonder what data I receive and what can i do when I
> link vitrage with kubernetes.
> As i know, the vitrage graph does not present information about containers
> or pods inside the vm. If that is correct, I would like to make the
> information of the pod level appear on the entity graph.
>
> I follow (
> https://docs.openstack.org/vitrage/latest/contributor/k8s_datasource.html)
> this step. I attached the vitage.conf file and the kubeconfig file. The
> contents of the Kubeconconfig file are copied from the contents of the
> admin.conf file on the master node.
> I want to check my settings are right and connected, but I don't know how.
> It would be very much appreciated if you let me know how.
>
Unfortunately, Vitrage does not hold pods and containers information at the
moment. We discussed the option of adding it in Stein release, but I'm not
sure we will get to do it.

Br,
Ifat

[1] https://review.openstack.org/#/c/611258/
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi Won,

On Wed, Oct 10, 2018 at 11:58 AM Won  wrote:

>
> my prometheus version : 2.3.2 and alertmanager version : 0.15.2 and I
> attached files.(vitrage collector,graph logs and apache log and
> prometheus.yml alertmanager.yml alarm rule file etc..)
> I think the problem that resolved alarm does not disappear is the time
> stamp problem of the alarm.
>
> -gray alarm info
> severity:PAGE
> vitrage id: c6a94386-3879-499e-9da0-2a5b9d3294b8  ,
> e2c5eae9-dba9-4f64-960b-b964f1c01dfe , 3d3c903e-fe09-4a6f-941f-1a2adb09feca
> , 8c6e7906-9e66-404f-967f-40037a6afc83 ,
> e291662b-115d-42b5-8863-da8243dd06b4 , 8abd2a2f-c830-453c-a9d0-55db2bf72d46
> --
>
> The alarms marked with the blue circle are already resolved. However, it
> does not disappear from the entity graph and alarm list.
> There were seven more gray alarms at the top screenshot in active alarms
> like entity graph. It disappeared by deleting gray alarms from the
> vitrage-alarms table in the DB or changing the end timestamp value to an
> earlier time than the current time.
>

I checked the files that you sent, and it appears that the connection
between Prometheus and Vitrage works well. I see in vitrage-graph log that
Prometheus notified both on alert firing and on alert resolved statuses.
I still don't understand why the alarms were not removed from Vitrage,
though. Can you please send me the output of 'vitrage topology show' CLI
command?
Also, did you happen to restart vitrage-graph or vitrage-collector during
your tests?


> At the log, it seems that the first problem is that the timestamp value
> from the vitrage comes to 2001-01-01, even though the starting value in the
> Prometheus alarm information has the correct value.
> When the alarm is solved, the end time stamp value is not updated so alarm
> does not disappear from the alarm list.
>

Can you please show me where you saw the 2001 timestamp? I didn't find it
in the log.


> The second problem is that even if the time stamp problem is solved, the
> entity graph problem will not be solved. Gray alarm information is not in
> the vitage-collector log but in the vitrage graph and apache log.
> I want to know how to forcefully delete entity from a vitage graph.
>

You shouldn't do it :-) there is no API for deleting entities, and messing
with the database may cause unexpected results.
The only thing that you can safely do is to stop all Vitrage services,
execute 'vitrage-purge-data' command, and start the services again. This
will cause rebuilding of the entity graph.


> Regarding the multi nodes, I mean, 1 controll node(pc1) & 1 compute
> node(pc2). So one openstack.
>
> The test VM in the picture is an instance on compute node that has already
> been deleted. I waited for hours and checked nova.conf but it was not
> removed.
> This was not the occur in the queens version; in the rocky version,
> multinode environment, there seems to be a bug in VM creation on multi node.
> The same situation occurred in multi-node environments that were
> configured with different PCs.
>

Let me make sure I understand the problem.
When you create a new vm in Nova, does it immediately appear in the entity
graph?
When you delete a vm, it remains? does it remain in a multi-node
environment and deleted in a single node environment?

Br,
Ifat
__
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

[openstack-dev] [vitrage] vitrage virtual PTG

[Ifat Afek]

Hi,

We will hold the vitrage virtual PTG on Wednesday-Thursday this week,
October 10-11th.
The agenda is listed in the etherpad[1], and you can still add new topics
for discussion.

We will skip the regular IRC meeting this week.

[1] https://etherpad.openstack.org/p/vitrage-stein-ptg

Thanks,
Ifat
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

Can you please give us some more details about your scenario with
Prometheus? Please try and give as many details as possible, so we can try
to reproduce the bug.


What do you mean by “if the alarm is resolved, the alarm manager makes a
silence, or removes the alarm rule from Prometheus”? these are different
cases. None of them works in your environment?

Which Prometheus and Alertmanager versions are you using?

 Please try to change the Vitrage loglevel to DEBUG (set “debug = true” in
/etc/vitrage/vitrage.conf) and send me the Vitrage collector, graph and api
logs.

Regarding the multi nodes, I'm not sure I understand your configuration. Do
you mean there is more than one OpenStack and Nova? more than one host?
more than one vm?

Basically, vms are deleted from Vitrage in two cases:
1. After each periodic call to get_all of nova.instance datasource. By
default this is done once in 10 minutes.
2. Immediately, if you have the following configuration in
/etc/nova/nova.conf:
notification_topics = notifications,vitrage_notifications

So, please check your nova.conf and also whether the vms are deleted after
10 minutes.

Thanks,
Ifat


On Thu, Oct 4, 2018 at 7:12 AM Won  wrote:

> Thank you for your reply Ifat.
>
> The alertmanager.yml file already contains 'send_resolved:true'.
> However, the alarm does not disappear from the alarm list and the entity
> graph even if the alarm is resolved, the alarm manager makes a silence, or
> removes the alarm rule from Prometheus.
> The only way to remove alarms is to manually remove them from the db. Is
> there any other way to remove the alarm?
> Entities(vm) that run on multi nodes in the rocky version have similar
> symptoms. There was a symptom that the Entities created on the multi-node
> would not disappear from the Entity Graph even after deletion.
> Is this a bug in rocky version?
>
> Best Regards,
> Won
>
>
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Won]

Thank you for your reply Ifat.

The alertmanager.yml file already contains 'send_resolved:true'.
However, the alarm does not disappear from the alarm list and the entity
graph even if the alarm is resolved, the alarm manager makes a silence, or
removes the alarm rule from Prometheus.
The only way to remove alarms is to manually remove them from the db. Is
there any other way to remove the alarm?
Entities(vm) that run on multi nodes in the rocky version have similar
symptoms. There was a symptom that the Entities created on the multi-node
would not disappear from the Entity Graph even after deletion.
Is this a bug in rocky version?

Best Regards,
Won

2018년 10월 3일 (수) 오후 5:46, Ifat Afek 님이 작성:

> Hi,
>
> In the alertmanager.yml file you should have a receiver for Vitrage.
> Please verify that it includes "send_resolved: true". This is required for
> Prometheus to notify Vitrage when an alarm is resolved.
>
> The full Vitrage receiver definition should be:
>
> - name: **
>
>   webhook_configs:
>
>   - url: **  # example: 'http://127.0.0.1:8999/v1/event
> '
>
> send_resolved: true
>
> http_config:
>
>   basic_auth:
>
> username: **
>
> password: **
>
> Hope it helps,
> Ifat
>
>
> On Tue, Oct 2, 2018 at 7:51 AM Won  wrote:
>
>> I have some problems with Prometheus alarms in vitrage.
>> I receive a list of alarms from the Prometheus alarm manager well, but
>> the alarm does not disappear when the problem(alarm) is resolved. The alarm
>> that came once in both the alarm list and the entity graph does not
>> disappear in vitrage.  The alarm sent by zabbix disappears when alarm
>> solved, I wonder how to clear the Prometheus alarm from vitrage and how to
>> update the alarm automatically like zabbix.
>> thank you.
>> __
>> 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
>>
> __
> 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
>
__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

In the alertmanager.yml file you should have a receiver for Vitrage. Please
verify that it includes "send_resolved: true". This is required for
Prometheus to notify Vitrage when an alarm is resolved.

The full Vitrage receiver definition should be:

- name: **

  webhook_configs:

  - url: **  # example: 'http://127.0.0.1:8999/v1/event'

send_resolved: true

http_config:

  basic_auth:

username: **

password: **

Hope it helps,
Ifat


On Tue, Oct 2, 2018 at 7:51 AM Won  wrote:

> I have some problems with Prometheus alarms in vitrage.
> I receive a list of alarms from the Prometheus alarm manager well, but the
> alarm does not disappear when the problem(alarm) is resolved. The alarm
> that came once in both the alarm list and the entity graph does not
> disappear in vitrage.  The alarm sent by zabbix disappears when alarm
> solved, I wonder how to clear the Prometheus alarm from vitrage and how to
> update the alarm automatically like zabbix.
> thank you.
> __
> 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
>
__
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

[openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Won]

I have some problems with Prometheus alarms in vitrage.
I receive a list of alarms from the Prometheus alarm manager well, but the
alarm does not disappear when the problem(alarm) is resolved. The alarm
that came once in both the alarm list and the entity graph does not
disappear in vitrage.  The alarm sent by zabbix disappears when alarm
solved, I wonder how to clear the Prometheus alarm from vitrage and how to
update the alarm automatically like zabbix.
thank you.
__
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

Re: [openstack-dev] [vitrage] I would like to know how to link vitrage and prometheus.

[ddaasd]

Hello Ifat,

Thank you for your help!
I really appreciate it. Thanks again!

Best Regards,
Won

2018년 9월 27일 (목) 오후 10:00, Ifat Afek 님이 작성:

> Hi,
>
> You can use the Prometheus datasource in Vitrage starting from Rocky
> release.
>
> In order to use it, follow these steps:
>
> 1. Add 'prometheus' to 'types' configuration under
> /etc/vitrage/vitrage.conf
> 2. In alertmanager.yml add a receiver as follows:
>
> - name: **
>
>   webhook_configs:
>
>   - url: **  # example: 'http://127.0.0.1:8999/v1/event
> '
>
> send_resolved: true
>
> http_config:
>
>   basic_auth:
>
> username: **
>
> password: **
>
>
>
> Br,
> Ifat
>
>
> On Thu, Sep 27, 2018 at 2:38 PM ddaasd  wrote:
>
>> I would like to know how to link vitrage and prometheus.
>> Is there a way to receive alert information from vitrage that occurred in
>> prometheus and Alert manager like zabbix-vitrage?
>> I wonder ,if i can, receive prometheus's alert and place it on the entity
>> graph in vitrage.
>> __
>> 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
>>
> __
> 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
>
__
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

Re: [openstack-dev] [vitrage] I would like to know how to link vitrage and prometheus.

[Ifat Afek]

Hi,

You can use the Prometheus datasource in Vitrage starting from Rocky
release.

In order to use it, follow these steps:

1. Add 'prometheus' to 'types' configuration under /etc/vitrage/vitrage.conf
2. In alertmanager.yml add a receiver as follows:

- name: **

  webhook_configs:

  - url: **  # example: 'http://127.0.0.1:8999/v1/event'

send_resolved: true

http_config:

  basic_auth:

username: **

password: **



Br,
Ifat


On Thu, Sep 27, 2018 at 2:38 PM ddaasd  wrote:

> I would like to know how to link vitrage and prometheus.
> Is there a way to receive alert information from vitrage that occurred in
> prometheus and Alert manager like zabbix-vitrage?
> I wonder ,if i can, receive prometheus's alert and place it on the entity
> graph in vitrage.
> __
> 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
>
__
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

[openstack-dev] [vitrage] I would like to know how to link vitrage and prometheus.

[ddaasd]

I would like to know how to link vitrage and prometheus.
Is there a way to receive alert information from vitrage that occurred in
prometheus and Alert manager like zabbix-vitrage?
I wonder ,if i can, receive prometheus's alert and place it on the entity
graph in vitrage.
__
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

[openstack-dev] [vitrage] I would like to know how to link vitrage and prometheus.

[ddaasd]

I would like to know how to link vitrage and prometheus.
Is there a way to receive alert information from vitrage that occurred in
prometheus and Alert manager like zabbix-vitrage?
I wonder ,if i can, receive prometheus's alert and place it on the entity
graph in vitrage.
__
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

[openstack-dev] [vitrage][ptg] Vitrage virtual PTG

[Ifat Afek]

Hi,

We will hold the Vitrage virtual PTG on October 10-11th.
You are welcome to join and suggest topics for discussion in the PTG
etherpad[1].

Thanks,
Ifat

[1] https://etherpad.openstack.org/p/vitrage-stein-ptg
__
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

[openstack-dev] [vitrage][ptl] PTL on vacation

[Ifat Afek]

Hi all,

I'll be on vacation between 12th and 31st of August. Anna Reznikov (
anna.rezni...@nokia.com) will replace me during this time and will handle
the Vitrage release.

Thanks,
Ifat
__
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

[openstack-dev] [vitrage][ptg] Vitrage virtual PTG

[Ifat Afek]

Hi,

As discussed in our IRC meeting yesterday [1], we will hold the Vitrage
virtual PTG on the first week of October. If you would like to participate,
you are welcome to add your name, time zone and ideas for discussion in the
PTG etherpad[2].

[1]
http://eavesdrop.openstack.org/meetings/vitrage/2018/vitrage.2018-08-01-08.00.log.html

[2] https://etherpad.openstack.org/p/vitrage-stein-ptg

Br,
Ifat
__
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

[openstack-dev] [Vitrage][PTL][Election] PTL candidacy for the Stein cycle

[Ifat Afek]

Hi all,

I would like to announce my candidacy to continue as Vitrage PTL for the
Stein
release.

I’ve been the PTL of Vitrage since the day it started. It has been an
amazing
journey, both for Vitrage and for me personally.

During the Rocky cycle, we have significantly enhanced the stability and
usability of Vitrage and we added support for integrating Vitrage with
several
other projects. We also took an active part in the self-healing SIG
discussions, as we believe Vitrage should hold an important role in every
self-healing scenario.

Among the most important tasks we did in Rocky were:

* Fast-failover of vitrage-graph
* Alarm history
* Significant performance improvements
* Kubernetes and Prometheus datasources

In Stein, I would like to continue the effort around Virage usability and
stability. In addition, we should integrate Vitrage with more projects,
to give the user maximum visibility of the state of the system.
On top of all the technical goals, I plan to continue the effort of
enlarging
our community. We are always looking for new contributors!

I look forward to working with you all in the coming cycle.

Thanks,
Ifat.
__
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

[openstack-dev] [vitrage] Vitrage was migrated to StoryBoard

[Ifat Afek]

Hi,

During the weekend we have completed the Vitrage migration to StoryBoard.

Vitrage bugs and blueprints should be handled in StoryBoard from now on.
All Vitrage bugs have been migrated and have the same bug number as in
launchpad. Regarding the blueprints, we migrated the ones that we are
currently working on in Rocky, but not the future ones.

We created an etherpad with guidelines regarding the new process [1]. Feel
free to comment and ask if something is unclear.

Special thanks to Kendall Nelson and fungi for their help.

[1] https://etherpad.openstack.org/p/vitrage-storyboard-migration

Ifat and Anna
__
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

Re: [openstack-dev] [Vitrage] naming issues

[Ifat Afek]

Hi,

Can you please send me your nagios_conf file, and the logs of
vitrage-collector and vitrage-graph?
I’ll have a look.

Thanks,
Ifat




On Thu, Jun 21, 2018 at 5:08 PM, Rafal Zielinski <
rafal.zielin...@linguamatics.com> wrote:

> Hello,
>
> As suggested by eyalb on irc I am posting my problem here.
>
> Basically I have 10 nova hosts named in nags as follows:
>
> nova0
> nova1
> .
> .
> .
> nova10
>
> I’ve made config file for the vitrage to map hosts to real hosts in
> Openstack named like:
>
> nova0.domain.com
> nova1.domain.com
> .
> .
> .
> nova10.domain.com
>
> And the issue:
> When provoking nagios alert on host nova10 Vitrage is displaying error on
> nova1, when provoking nagios alert on host nova1 vitrage is not showing any
> alert.
>
> Can somebody have a look at this issue ?
>
> Thank you,
> Rafal Zielinski
>
>
> __
> 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
>
__
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

[openstack-dev] [Vitrage] naming issues

[Rafal Zielinski]

Hello,

As suggested by eyalb on irc I am posting my problem here.

Basically I have 10 nova hosts named in nags as follows:

nova0
nova1
.
.
.
nova10

I’ve made config file for the vitrage to map hosts to real hosts in Openstack 
named like:

nova0.domain.com
nova1.domain.com
.
.
.
nova10.domain.com

And the issue:
When provoking nagios alert on host nova10 Vitrage is displaying error on 
nova1, when provoking nagios alert on host nova1 vitrage is not showing any 
alert.

Can somebody have a look at this issue ?

Thank you,
Rafal Zielinski


__
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

Re: [openstack-dev] [vitrage] matching webhook vs alarm list

[Eric K]

Thank you for the explanation!

Eric

From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, June 11, 2018 at 1:34 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] matching webhook vs alarm list

> Hi Eric,
>  
> The format of the vitrage_id was changed to UUID in Pike release. It appears
> that the API documentation [1] is outdated. I¹ll fix it.
> The vitrage_id that you get in the webhook notification should match the one
> coming from Œvitrage alarm list¹. The Œid¹ field is determined by the external
> monitor, so it might be different.
>  
> Best Regards,
> Ifat
>  
> 
> -- Forwarded message -----
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 01:40
> Subject: [openstack-dev] [vitrage] matching webhook vs alarm list
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on what ID to use for matching a webhook notification to
> the specific alarm from the alarm list. In the sample alarm list
> response, there is an 'id' field and a 'vitrage_id' field [1], where
> as in the sample webhook notification payload, there is a 'vitrage_id'
> field [2]. I'd assume we can match by the 'vitrage_id', but the
> samples have very different formats for 'vitrage_id', so I just want
> to confirm. Thank you!
> 
> [1] 
> https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
> [2]
> {
>   "notification": "vitrage.alarm.activate",
>   "payload": {
> "vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
> "resource": {
>   "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
>   "name": "app-1-server-1-jz6qvznkmnif",
>   "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
>   "vitrage_category": "RESOURCE",
>   "vitrage_operational_state": "OK",
>   "vitrage_type": "nova.instance",
>   "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
>   "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
> },
> "update_timestamp": "2018-01-22T10:00:34Z",
> "vitrage_category": "ALARM",
> "state": "Active",
> "vitrage_type": "vitrage",
> "vitrage_operational_severity": "WARNING",
> "name": "Instance memory performance degraded"
>   }
> }
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.
> html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> 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


__
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

Re: [openstack-dev] [vitrage] update_timestamp precision

[Eric K]

Thank you, Ifat!
From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, June 11, 2018 at 2:12 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] update_timestamp precision

> Hi Eric,
>  
> Apparently we have inconsistent behavior between the different datasources.
> The format of the timestamp should be '%Y-%m-%dT%H:%M:%SZ' as defined in [1].
> We need to go over the code and make sure all datasources are aligned. I
> created a bug for it [2].
>  
> [1] 
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/transform
> er_base.py
> 
> [2] https://bugs.launchpad.net/vitrage/+bug/1776181
> Best regards,
> Ifat
>  
> 
> -- Forwarded message ---------
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 00:20
> Subject: [openstack-dev] [vitrage] update_timestamp precision
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on the timestamp precision to expect.
> 
> In the sample webhook payload found in doc the resource and the alarm
> shows different time stamp precisions:
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
> in.html 
> <https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin
> .html> 
> 
> 
> Thank you!
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> 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


__
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

Re: [openstack-dev] [vitrage] update_timestamp precision

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Eric,

Apparently we have inconsistent behavior between the different datasources. The 
format of the timestamp should be '%Y-%m-%dT%H:%M:%SZ' as defined in [1]. We 
need to go over the code and make sure all datasources are aligned. I created a 
bug for it [2].

[1] 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/transformer_base.py
[2] https://bugs.launchpad.net/vitrage/+bug/1776181
Best regards,
Ifat

-- Forwarded message -
From: Eric K mailto:ekcs.openst...@gmail.com>>
Date: Sat, 9 Jun 2018 at 00:20
Subject: [openstack-dev] [vitrage] update_timestamp precision
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>


Hi I'm building integration with Vitrage webhook and looking for some
clarification on the timestamp precision to expect.

In the sample webhook payload found in doc the resource and the alarm
shows different time stamp precisions:
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
in.html


Thank you!



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] [vitrage] matching webhook vs alarm list

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Eric,

The format of the vitrage_id was changed to UUID in Pike release. It appears 
that the API documentation [1] is outdated. I’ll fix it.
The vitrage_id that you get in the webhook notification should match the one 
coming from ‘vitrage alarm list’. The ‘id’ field is determined by the external 
monitor, so it might be different.

Best Regards,
Ifat

-- Forwarded message -
From: Eric K mailto:ekcs.openst...@gmail.com>>
Date: Sat, 9 Jun 2018 at 01:40
Subject: [openstack-dev] [vitrage] matching webhook vs alarm list
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>


Hi I'm building integration with Vitrage webhook and looking for some
clarification on what ID to use for matching a webhook notification to
the specific alarm from the alarm list. In the sample alarm list
response, there is an 'id' field and a 'vitrage_id' field [1], where
as in the sample webhook notification payload, there is a 'vitrage_id'
field [2]. I'd assume we can match by the 'vitrage_id', but the
samples have very different formats for 'vitrage_id', so I just want
to confirm. Thank you!

[1] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
[2]
{
  "notification": "vitrage.alarm.activate",
  "payload": {
"vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
"resource": {
  "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
  "name": "app-1-server-1-jz6qvznkmnif",
  "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
  "vitrage_category": "RESOURCE",
  "vitrage_operational_state": "OK",
  "vitrage_type": "nova.instance",
  "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
  "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
},
"update_timestamp": "2018-01-22T10:00:34Z",
"vitrage_category": "ALARM",
"state": "Active",
"vitrage_type": "vitrage",
"vitrage_operational_severity": "WARNING",
"name": "Instance memory performance degraded"
  }
}
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

[openstack-dev] [vitrage] matching webhook vs alarm list

[Eric K]

Hi I'm building integration with Vitrage webhook and looking for some
clarification on what ID to use for matching a webhook notification to
the specific alarm from the alarm list. In the sample alarm list
response, there is an 'id' field and a 'vitrage_id' field [1], where
as in the sample webhook notification payload, there is a 'vitrage_id'
field [2]. I'd assume we can match by the 'vitrage_id', but the
samples have very different formats for 'vitrage_id', so I just want
to confirm. Thank you!

[1] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
[2]
{
  "notification": "vitrage.alarm.activate",
  "payload": {
"vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
"resource": {
  "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
  "name": "app-1-server-1-jz6qvznkmnif",
  "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
  "vitrage_category": "RESOURCE",
  "vitrage_operational_state": "OK",
  "vitrage_type": "nova.instance",
  "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
  "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
},
"update_timestamp": "2018-01-22T10:00:34Z",
"vitrage_category": "ALARM",
"state": "Active",
"vitrage_type": "vitrage",
"vitrage_operational_severity": "WARNING",
"name": "Instance memory performance degraded"
  }
}
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.html

__
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

[openstack-dev] [vitrage] update_timestamp precision

[Eric K]

Hi I'm building integration with Vitrage webhook and looking for some
clarification on the timestamp precision to expect.

In the sample webhook payload found in doc the resource and the alarm
shows different time stamp precisions:
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
in.html


Thank you!



__
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

[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting this week is canceled, since many Vitrage developers are on 
vacation.

We will meet next Wednesday, June 6th, at 8:00 UTC.

See you next week,
Ifat

__
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

[openstack-dev] [vitrage] etherpads for Vitrage forum sessions

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I created etherpads for Vitrage forum sessions:


- Advanced RCA use cases - taking Vitrage to the next level: 
https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases 
- Vitrage RCA over K8s. Pets and Cattle - Monitor each cow? : 
https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s 

You are welcome to comment and propose more topics for discussion.

Thanks, 
Ifat





__
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

Re: [openstack-dev] [Vitrage] Vitrage graph error

[MinWookKim]

Hello Ifat,

 

The problem is resolved. :)

 

Thank you.

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Sunday, April 29, 2018 3:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

 

Hi Minwook,

 

The following change should fix your problem:

https://review.openstack.org/#/c/564471/

 

Let me know if it helped.

 

Thanks,

Ifat

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 24 April 2018 at 10:59
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

 

Hello Ifat, 

 

I have not checked the alarm yet. (I think it does not work.)

 

However, i confirmed that the entity graph and the topology do not work.

 

Additionally, the CLI does not seem to work either.

 

I'll check it out with you. : )

 

Thank you.

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 24, 2018 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

 

Hi Minwook,

 

Is the problem only in the Entity Graph? Do the Alarms view and the
Topology view work?

And what about the CLI?

 

I’ll check it and get back to you.

 

Thanks,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: [openstack-dev] [Vitrage] Vitrage graph error

 

Hello Vitrage team,

 

A few days ago I used Devstack to install the Openstack master version,
which included Vitrage.

 

However, I found that the Vitrage graph does not work on the
Vitrage-dashboard.

 

The state of all Vitrage components is active.

 

Could you check it once?

 

Thanks.

 

Best Regards,

 

Minwook.

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

Re: [openstack-dev] [Vitrage] Vitrage graph error

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

The following change should fix your problem:
https://review.openstack.org/#/c/564471/

Let me know if it helped.

Thanks,
Ifat

From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 24 April 2018 at 10:59
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

Hello Ifat,

I have not checked the alarm yet. (I think it does not work.)

However, i confirmed that the entity graph and the topology do not work.

Additionally, the CLI does not seem to work either.

I'll check it out with you. : )

Thank you.

Best Regards,
Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Tuesday, April 24, 2018 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

Hi Minwook,

Is the problem only in the Entity Graph? Do the Alarms view and the Topology 
view work?
And what about the CLI?

I’ll check it and get back to you.

Thanks,
Ifat


From: MinWookKim <delightw...@ssu.ac.kr<mailto:delightw...@ssu.ac.kr>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Vitrage] Vitrage graph error

Hello Vitrage team,

A few days ago I used Devstack to install the Openstack master version, which 
included Vitrage.

However, I found that the Vitrage graph does not work on the Vitrage-dashboard.

The state of all Vitrage components is active.

Could you check it once?

Thanks.

Best Regards,

Minwook.
__
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

Re: [openstack-dev] [Vitrage] Vitrage graph error

[MinWookKim]

Hello Ifat, 

 

I have not checked the alarm yet. (I think it does not work.)

 

However, i confirmed that the entity graph and the topology do not work.

 

Additionally, the CLI does not seem to work either.

 

I'll check it out with you. : )

 

Thank you.

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 24, 2018 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

 

Hi Minwook,

 

Is the problem only in the Entity Graph? Do the Alarms view and the
Topology view work?

And what about the CLI?

 

I’ll check it and get back to you.

 

Thanks,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: [openstack-dev] [Vitrage] Vitrage graph error

 

Hello Vitrage team,

 

A few days ago I used Devstack to install the Openstack master version,
which included Vitrage.

 

However, I found that the Vitrage graph does not work on the
Vitrage-dashboard.

 

The state of all Vitrage components is active.

 

Could you check it once?

 

Thanks.

 

Best Regards,

 

Minwook.

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

Re: [openstack-dev] [Vitrage] Vitrage graph error

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Is the problem only in the Entity Graph? Do the Alarms view and the Topology 
view work?
And what about the CLI?

I’ll check it and get back to you.

Thanks,
Ifat


From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Vitrage] Vitrage graph error

Hello Vitrage team,

A few days ago I used Devstack to install the Openstack master version, which 
included Vitrage.

However, I found that the Vitrage graph does not work on the Vitrage-dashboard.

The state of all Vitrage components is active.

Could you check it once?

Thanks.

Best Regards,

Minwook.
__
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

[openstack-dev] [Vitrage] Vitrage graph error

[MinWookKim]

Hello Vitrage team,

 

A few days ago I used Devstack to install the Openstack master version,
which included Vitrage.

 

However, I found that the Vitrage graph does not work on the
Vitrage-dashboard.

 

The state of all Vitrage components is active.

 

Could you check it once?

 

Thanks.

 

Best Regards,

 

Minwook.

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

[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting tomorrow (April 18th) is canceled, as many Vitrage developers 
will be on vacation.

See you next week,
Ifat

__
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

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

I'll update the BP soon. : )


Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Sunday, April 8, 2018 6:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Sounds like a good idea :)

 

Thanks,

Ifat

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Friday, 6 April 2018 at 12:07
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

If possible, could i write a blueprint based on what we discussed?
(architecture, specs)

 

After checking the blueprint, it would be better to proceed with specific
updates on the various issues.

what do you think?

 

Thanks.

 

Best regards,

Minwook.

From: MinWookKim [mailto:delightw...@ssu.ac.kr] 
Sent: Thursday, April 5, 2018 10:53 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: RE: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for the good comments.

 

It was very helpful.

 

As you said, I tested for std.ssh, and I was able to get much better
results.

 

I am confident that this is what I want.

 

We can use std.ssh to provide convenience to users with a much more
efficient way to configure shell scripts / monitoring agent automation(for
Zabbix history,etc) / other commands.

 

In addition, std_actions.py contained a number of features that could be
used for this proposal (such as HTTP).

 

So if we actively use and utilize the actions in std_actions.py, we might
be able to construct neat code without the duplicate functionality that you
worried about.

 

It has been a great help.

 

In addition, I also agree that Vitrage action is required for Mistral.

 

If possible, I might be able to do that in the future.(ASAP)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, April 4, 2018 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I discussed this issue with a Mistral contributor. 

Mistral has a long list of actions that can be used. Specifically, you can
use the std.ssh action to execute shell scripts.

 

Some useful commands:

 

mistral action-list

mistral action-get 

 

I’m not sure about the output of the std.ssh, and whether you can get it
from the action. I suggest you try it and see how it works.

The action is implemented here:
https://github.com/openstack/mistral/blob/master/mistral/actions/std_actions
.py 

 

If std.ssh does not suit your needs, you also have an option to implement
and run your own action in Mistral (either as an ssh action or as a python
code). 

And BTW, it is not related to your current use case, but we can also add
Vitrage actions to Mistral, so the user can access Vitrage information (get
topology, get alarms) from Mistral workflows. 

 

Best regards,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 15:19
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.

 

Your comments have been a great help to the proposal.  (sorry, I did not
think we could use Mistral).

 

If we use the Mistral workflow for the proposal, we can get better results
(we can get good results on performance and code conciseness).

 

Also, if we use the Mistral workflow, we do not need to write any
unnecessary code.

 

Since I don't know about mistral yet, I think it would be better to do the
most efficient design including mistral after grasping it.

 

If we run a check through a Mistral workflow, how about providing users
with a choice of tools that have the capability to perform checks?

 

We can get the results of the check through the Mistral and tools, but I
think we need the least functionality to manage them. What do you think?

 

I attached a picture of the actual UI that I simply implemented. I hope it
helps you understand. (The parameter and content have no meaning and are a
simple example.) : )

 

Th

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

If possible, could i write a blueprint based on what we discussed?
(architecture, specs)

 

After checking the blueprint, it would be better to proceed with specific
updates on the various issues.

what do you think?

 

Thanks.

 

Best regards,

Minwook.

From: MinWookKim [mailto:delightw...@ssu.ac.kr] 
Sent: Thursday, April 5, 2018 10:53 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: RE: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for the good comments.

 

It was very helpful.

 

As you said, I tested for std.ssh, and I was able to get much better
results.

 

I am confident that this is what I want.

 

We can use std.ssh to provide convenience to users with a much more
efficient way to configure shell scripts / monitoring agent automation(for
Zabbix history,etc) / other commands.

 

In addition, std_actions.py contained a number of features that could be
used for this proposal (such as HTTP).

 

So if we actively use and utilize the actions in std_actions.py, we might
be able to construct neat code without the duplicate functionality that you
worried about.

 

It has been a great help.

 

In addition, I also agree that Vitrage action is required for Mistral.

 

If possible, I might be able to do that in the future.(ASAP)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, April 4, 2018 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I discussed this issue with a Mistral contributor. 

Mistral has a long list of actions that can be used. Specifically, you can
use the std.ssh action to execute shell scripts.

 

Some useful commands:

 

mistral action-list

mistral action-get 

 

I’m not sure about the output of the std.ssh, and whether you can get it
from the action. I suggest you try it and see how it works.

The action is implemented here:
https://github.com/openstack/mistral/blob/master/mistral/actions/std_actions
.py 

 

If std.ssh does not suit your needs, you also have an option to implement
and run your own action in Mistral (either as an ssh action or as a python
code). 

And BTW, it is not related to your current use case, but we can also add
Vitrage actions to Mistral, so the user can access Vitrage information (get
topology, get alarms) from Mistral workflows. 

 

Best regards,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 15:19
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.

 

Your comments have been a great help to the proposal.  (sorry, I did not
think we could use Mistral).

 

If we use the Mistral workflow for the proposal, we can get better results
(we can get good results on performance and code conciseness).

 

Also, if we use the Mistral workflow, we do not need to write any
unnecessary code.

 

Since I don't know about mistral yet, I think it would be better to do the
most efficient design including mistral after grasping it.

 

If we run a check through a Mistral workflow, how about providing users
with a choice of tools that have the capability to perform checks?

 

We can get the results of the check through the Mistral and tools, but I
think we need the least functionality to manage them. What do you think?

 

I attached a picture of the actual UI that I simply implemented. I hope it
helps you understand. (The parameter and content have no meaning and are a
simple example.) : )

 

Thanks.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 3, 2018 8:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Thanks for the explanation, I understand the reasons for not running these
checks on a regular basis in Zabbix or other monitoring tools. It makes
sense. However, I don’t want to re-invent the wheel and add to Vitrage
functionality that already exists in other projects. 

 

How about using Mistral for the purpose of manually running these extra
checks? If you prepare the script/agent in advance, as well as the Mistral
workflow, I believe that Mistral can successfully execute the check and
return the results. I’m not so sure about the UI part, we will have to
figure out how and where the user can see the output. But it will save a

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

Thanks for the good comments.

 

It was very helpful.

 

As you said, I tested for std.ssh, and I was able to get much better
results.

 

I am confident that this is what I want.

 

We can use std.ssh to provide convenience to users with a much more
efficient way to configure shell scripts / monitoring agent automation(for
Zabbix history,etc) / other commands.

 

In addition, std_actions.py contained a number of features that could be
used for this proposal (such as HTTP).

 

So if we actively use and utilize the actions in std_actions.py, we might
be able to construct neat code without the duplicate functionality that you
worried about.

 

It has been a great help.

 

In addition, I also agree that Vitrage action is required for Mistral.

 

If possible, I might be able to do that in the future.(ASAP)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, April 4, 2018 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I discussed this issue with a Mistral contributor. 

Mistral has a long list of actions that can be used. Specifically, you can
use the std.ssh action to execute shell scripts.

 

Some useful commands:

 

mistral action-list

mistral action-get 

 

I’m not sure about the output of the std.ssh, and whether you can get it
from the action. I suggest you try it and see how it works.

The action is implemented here:
https://github.com/openstack/mistral/blob/master/mistral/actions/std_actions
.py 

 

If std.ssh does not suit your needs, you also have an option to implement
and run your own action in Mistral (either as an ssh action or as a python
code). 

And BTW, it is not related to your current use case, but we can also add
Vitrage actions to Mistral, so the user can access Vitrage information (get
topology, get alarms) from Mistral workflows. 

 

Best regards,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 15:19
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.

 

Your comments have been a great help to the proposal.  (sorry, I did not
think we could use Mistral).

 

If we use the Mistral workflow for the proposal, we can get better results
(we can get good results on performance and code conciseness).

 

Also, if we use the Mistral workflow, we do not need to write any
unnecessary code.

 

Since I don't know about mistral yet, I think it would be better to do the
most efficient design including mistral after grasping it.

 

If we run a check through a Mistral workflow, how about providing users
with a choice of tools that have the capability to perform checks?

 

We can get the results of the check through the Mistral and tools, but I
think we need the least functionality to manage them. What do you think?

 

I attached a picture of the actual UI that I simply implemented. I hope it
helps you understand. (The parameter and content have no meaning and are a
simple example.) : )

 

Thanks.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 3, 2018 8:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Thanks for the explanation, I understand the reasons for not running these
checks on a regular basis in Zabbix or other monitoring tools. It makes
sense. However, I don’t want to re-invent the wheel and add to Vitrage
functionality that already exists in other projects. 

 

How about using Mistral for the purpose of manually running these extra
checks? If you prepare the script/agent in advance, as well as the Mistral
workflow, I believe that Mistral can successfully execute the check and
return the results. I’m not so sure about the UI part, we will have to
figure out how and where the user can see the output. But it will save a lot
of effort around managing the checks, running a new service, supporting a
new API, etc.

 

What do you think?

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 5:36
To: "'OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Thanks for the explanation, I understand the reasons for not running these 
checks on a regular basis in Zabbix or other monitoring tools. It makes sense. 
However, I don’t want to re-invent the wheel and add to Vitrage functionality 
that already exists in other projects.

How about using Mistral for the purpose of manually running these extra checks? 
If you prepare the script/agent in advance, as well as the Mistral workflow, I 
believe that Mistral can successfully execute the check and return the results. 
I’m not so sure about the UI part, we will have to figure out how and where the 
user can see the output. But it will save a lot of effort around managing the 
checks, running a new service, supporting a new API, etc.

What do you think?
Ifat


From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 3 April 2018 at 5:36
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

I also thought about several scenarios that use monitoring tools like Zabbix, 
Nagios, and Prometheus.

But there are some limitations, so we have to think about it.

We also need to think about targets, scope, and so on.

The reason I do not think of tools like Zabbix, Nagios, and Prometheus as a 
tool to run checks is because we need to configure an agent or an exporter.

I think it is not hard to configure an agent for monitoring objects such as a 
physical host.

But the scope of the idea I think involves the VM's interior.

Therefore, configuring the agent automatically inside the VM may not be easy. 
(although we can use parameters like user-data)

If we exclude VM internal checks from scope, we can simply perform a check via 
Zabbix. (Like Zabbix's remote command, history)

On the other hand, if we include the inside of a VM in a scope, and configure 
each of them, we have a rather constant overhead.

The check service may incur temporary overhead, but the agent configuration can 
cause constant overhead.

And Zabbix history can be another task for Vitrage.

If we configure the agents themselves and exclude the VM's internal checks, we 
can provide functionality with simple code.

how is it?

Thank you.

Best regards,
Minwook.
From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Monday, April 2, 2018 10:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hi Minwook,

Thinking about it again, writing a new service for these checks might be an 
unnecessary overhead. Have you considered using an existing tool, like Zabbix, 
for running such checks? If you use Zabbix, you can define new triggers that 
run the new checks, and whenever needed the user can ask to open Zabbix and 
show the relevant metrics. The format will not be exactly the same as in your 
example, but it will save a lot of work and spare you the need to write and 
manage a new service.

Some technical details:


· The current information that Vitrage stores is not enough for opening 
the right Zabbix page. We will need to keep a little more data, like the item 
id, on the alarm vertex. But can be done easily.

· A relevant Zabbix API is history.get [1]

· If you are not using Zabbix, I assume that other monitoring tools 
have similar capabilities

What do you think? Do you think it can work with your scenario?
Or do you see a benefit to the user is viewing the data in the format that you 
suggested?


[1] https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get

Thanks,
Ifat


From: MinWookKim <delightw...@ssu.ac.kr<mailto:delightw...@ssu.ac.kr>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, 2 April 2018 at 4:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thank you for the reply. :)

It is my opinion only, so if I'm wrong, we can change the implementation part 
at any time. (Even if it differs from my initial intention)

The same security issues arise as you say. But now Vitrage does not call 
external APIs.

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms, and 
RCA requests to Vitrage.

So if we add an API, it will have the following flow.

Vitrage-dashboard requests checks using the Vitrageclient library. -> Vitrage 
receives the API.

-> api / controllers / v1 / checks.py is called. -> checks service is called.

In accordance with the a

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat, 

 

I also thought about several scenarios that use monitoring tools like
Zabbix, Nagios, and Prometheus.

 

But there are some limitations, so we have to think about it.

 

We also need to think about targets, scope, and so on.

 

The reason I do not think of tools like Zabbix, Nagios, and Prometheus as a
tool to run checks is because we need to configure an agent or an exporter.

 

I think it is not hard to configure an agent for monitoring objects such as
a physical host.

 

But the scope of the idea I think involves the VM's interior. 

 

Therefore, configuring the agent automatically inside the VM may not be
easy. (although we can use parameters like user-data)

 

If we exclude VM internal checks from scope, we can simply perform a check
via Zabbix. (Like Zabbix's remote command, history)

 

On the other hand, if we include the inside of a VM in a scope, and
configure each of them, we have a rather constant overhead.

 

The check service may incur temporary overhead, but the agent configuration
can cause constant overhead.

 

And Zabbix history can be another task for Vitrage.

 

If we configure the agents themselves and exclude the VM's internal checks,
we can provide functionality with simple code.

 

how is it?

 

Thank you.

 

Best regards,

Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Monday, April 2, 2018 10:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Thinking about it again, writing a new service for these checks might be an
unnecessary overhead. Have you considered using an existing tool, like
Zabbix, for running such checks? If you use Zabbix, you can define new
triggers that run the new checks, and whenever needed the user can ask to
open Zabbix and show the relevant metrics. The format will not be exactly
the same as in your example, but it will save a lot of work and spare you
the need to write and manage a new service. 

 

Some technical details: 

 

* The current information that Vitrage stores is not enough for
opening the right Zabbix page. We will need to keep a little more data, like
the item id, on the alarm vertex. But can be done easily. 

* A relevant Zabbix API is history.get [1]

* If you are not using Zabbix, I assume that other monitoring tools
have similar capabilities

 

What do you think? Do you think it can work with your scenario?

Or do you see a benefit to the user is viewing the data in the format that
you suggested?

 

 

[1]
<https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get>
https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get

 

Thanks,

Ifat

 

 

From: MinWookKim < <mailto:delightw...@ssu.ac.kr> delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
<mailto:openstack-dev@lists.openstack.org>
openstack-dev@lists.openstack.org>
Date: Monday, 2 April 2018 at 4:51
To: "'OpenStack Development Mailing List (not for usage questions)'" <
<mailto:openstack-dev@lists.openstack.org>
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thank you for the reply. :)

 

It is my opinion only, so if I'm wrong, we can change the implementation
part at any time. (Even if it differs from my initial intention)

 

The same security issues arise as you say. But now Vitrage does not call
external APIs.

 

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms,
and RCA requests to Vitrage.

 

So if we add an API, it will have the following flow.

 

Vitrage-dashboard requests checks using the Vitrageclient library. ->
Vitrage receives the API.

 

-> api / controllers / v1 / checks.py is called. -> checks service is
called.

 

In accordance with the above flow, passing through the Vitrage API is the
purpose of data passing and function calls. 

 

I think Vitrage does not need to call external APIs.

 

If you do not want to go through the Vitrage API, we need to create a
function for the check action in the Vitrage-dashboard, and write code to
call the function.

 

If I think wrong, please tell me anytime. :)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [ <mailto:ifat.a...@nokia.com>
mailto:ifat.a...@nokia.com] 
Sent: Sunday, April 1, 2018 3:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I understand your concern about the security issue. 

But how would that be different if the API call is passed through Vitrage
API? The authentication from vitrage-dashboard to vitrage API will work, but
then Vitrage will call an external API and you’ll have the same security
issue, right? I d

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Thinking about it again, writing a new service for these checks might be an 
unnecessary overhead. Have you considered using an existing tool, like Zabbix, 
for running such checks? If you use Zabbix, you can define new triggers that 
run the new checks, and whenever needed the user can ask to open Zabbix and 
show the relevant metrics. The format will not be exactly the same as in your 
example, but it will save a lot of work and spare you the need to write and 
manage a new service.

Some technical details:


· The current information that Vitrage stores is not enough for opening 
the right Zabbix page. We will need to keep a little more data, like the item 
id, on the alarm vertex. But can be done easily.

· A relevant Zabbix API is history.get [1]

· If you are not using Zabbix, I assume that other monitoring tools 
have similar capabilities

What do you think? Do you think it can work with your scenario?
Or do you see a benefit to the user is viewing the data in the format that you 
suggested?


[1] https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get

Thanks,
Ifat


From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 2 April 2018 at 4:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thank you for the reply. :)

It is my opinion only, so if I'm wrong, we can change the implementation part 
at any time. (Even if it differs from my initial intention)

The same security issues arise as you say. But now Vitrage does not call 
external APIs.

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms, and 
RCA requests to Vitrage.

So if we add an API, it will have the following flow.

Vitrage-dashboard requests checks using the Vitrageclient library. -> Vitrage 
receives the API.

-> api / controllers / v1 / checks.py is called. -> checks service is called.

In accordance with the above flow, passing through the Vitrage API is the 
purpose of data passing and function calls.

I think Vitrage does not need to call external APIs.

If you do not want to go through the Vitrage API, we need to create a function 
for the check action in the Vitrage-dashboard, and write code to call the 
function.

If I think wrong, please tell me anytime. :)

Thank you.

Best regards,
Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Sunday, April 1, 2018 3:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hi Minwook,

I understand your concern about the security issue.
But how would that be different if the API call is passed through Vitrage API? 
The authentication from vitrage-dashboard to vitrage API will work, but then 
Vitrage will call an external API and you’ll have the same security issue, 
right? I don’t understand what is the difference between calling the external 
component from vitrage-dashboard and calling it from vitrage.

Best regards,
Ifat.

From: MinWookKim <delightw...@ssu.ac.kr<mailto:delightw...@ssu.ac.kr>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 29 March 2018 at 14:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thanks for your reply.  : )
I wrote my opinion on your comment.

Why do you think the request should pass through the Vitrage API? Why can’t 
vitrage-dashboard call the check component directly?

Authentication issues:
I think the check component is a separate component based on the API.

In my opinion, if the check component has a separate api address from the 
vitrage to receive requests from the Vitrage-dashboard,
the Vitrage-dashboard needs to know the api address for the check component.

This can result in a request / response situation open to anyone, regardless of 
the authentication supported
by openstack between the Vitrage-dashboard and the request / response procedure 
of check component.

This is possible not only through the Vitrage-dashboard, but also with simple 
commands such as curl.
(I think it is unnecessary to implement a separate authentication system for 
the check component.)

This problem may occur if someone knows the api address for the check component,
which can cause the host and VM to execute system commands.

what should happen if the user closes the check window before the checks are 
over? I assume that the checks

[openstack-dev] [vitrage]

[Hanumantha Reddy]

__
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

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

Thank you for the reply. :)

 

It is my opinion only, so if I'm wrong, we can change the implementation
part at any time. (Even if it differs from my initial intention)

 

The same security issues arise as you say. But now Vitrage does not call
external APIs.

 

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms,
and RCA requests to Vitrage.

 

So if we add an API, it will have the following flow.

 

Vitrage-dashboard requests checks using the Vitrageclient library. ->
Vitrage receives the API.

 

-> api / controllers / v1 / checks.py is called. -> checks service is
called.

 

In accordance with the above flow, passing through the Vitrage API is the
purpose of data passing and function calls. 

 

I think Vitrage does not need to call external APIs.

 

If you do not want to go through the Vitrage API, we need to create a
function for the check action in the Vitrage-dashboard, and write code to
call the function.

 

If I think wrong, please tell me anytime. :)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Sunday, April 1, 2018 3:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I understand your concern about the security issue. 

But how would that be different if the API call is passed through Vitrage
API? The authentication from vitrage-dashboard to vitrage API will work, but
then Vitrage will call an external API and you’ll have the same security
issue, right? I don’t understand what is the difference between calling the
external component from vitrage-dashboard and calling it from vitrage.

 

Best regards,

Ifat.

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Thursday, 29 March 2018 at 14:51
To: "'OpenStack Development Mailing List (not for usage questions)'"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.  : )

I wrote my opinion on your comment.

 

Why do you think the request should pass through the Vitrage API? Why can’t
vitrage-dashboard call the check component directly?

 

Authentication issues:

I think the check component is a separate component based on the API.

 

In my opinion, if the check component has a separate api address from the
vitrage to receive requests from the Vitrage-dashboard, 

the Vitrage-dashboard needs to know the api address for the check
component.

 

This can result in a request / response situation open to anyone,
regardless of the authentication supported 

by openstack between the Vitrage-dashboard and the request / response
procedure of check component.

 

This is possible not only through the Vitrage-dashboard, but also with
simple commands such as curl. 

(I think it is unnecessary to implement a separate authentication system
for the check component.)

 

This problem may occur if someone knows the api address for the check
component, 

which can cause the host and VM to execute system commands.

 

what should happen if the user closes the check window before the checks
are over? I assume that the checks will finish, but the user won’t be able
to see the results?

 

If the window is closed before the check is finished, the user can not
check the result.

 

To solve this problem, I think that temporarily saving a list of recent
results is also a solution.

 

By storing temporary lists (for example, up to 10), the user can see the
previous results and think that it is also possible to empty the list by the
user.

 

how is it?

 

Thank you.

 

Best Regrads,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Thursday, March 29, 2018 8:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Why do you think the request should pass through the Vitrage API? Why can’t
vitrage-dashboard call the check component directly?

 

And another question: what should happen if the user closes the check
window before the checks are over? I assume that the checks will finish, but
the user won’t be able to see the results?

 

Thanks,

Ifat.

 

From: MinWookKim < <mailto:delightw...@ssu.ac.kr> delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
<mailto:openstack-dev@lists.openstack.org>
openstack-dev@lists.openstack.org>
Date: Thursday, 29 March 2018 at 10:25
To: "'OpenStack Development Mailing List (not for usage questions)'"

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

I understand your concern about the security issue.
But how would that be different if the API call is passed through Vitrage API? 
The authentication from vitrage-dashboard to vitrage API will work, but then 
Vitrage will call an external API and you’ll have the same security issue, 
right? I don’t understand what is the difference between calling the external 
component from vitrage-dashboard and calling it from vitrage.

Best regards,
Ifat.

From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 29 March 2018 at 14:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thanks for your reply.  : )

I wrote my opinion on your comment.

Why do you think the request should pass through the Vitrage API? Why can’t 
vitrage-dashboard call the check component directly?

Authentication issues:
I think the check component is a separate component based on the API.

In my opinion, if the check component has a separate api address from the 
vitrage to receive requests from the Vitrage-dashboard,
the Vitrage-dashboard needs to know the api address for the check component.

This can result in a request / response situation open to anyone, regardless of 
the authentication supported
by openstack between the Vitrage-dashboard and the request / response procedure 
of check component.

This is possible not only through the Vitrage-dashboard, but also with simple 
commands such as curl.
(I think it is unnecessary to implement a separate authentication system for 
the check component.)

This problem may occur if someone knows the api address for the check component,
which can cause the host and VM to execute system commands.

what should happen if the user closes the check window before the checks are 
over? I assume that the checks will finish, but the user won’t be able to see 
the results?

If the window is closed before the check is finished, the user can not check 
the result.

To solve this problem, I think that temporarily saving a list of recent results 
is also a solution.

By storing temporary lists (for example, up to 10), the user can see the 
previous results and think that it is also possible to empty the list by the 
user.

how is it?

Thank you.

Best Regrads,
Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, March 29, 2018 8:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hi Minwook,

Why do you think the request should pass through the Vitrage API? Why can’t 
vitrage-dashboard call the check component directly?

And another question: what should happen if the user closes the check window 
before the checks are over? I assume that the checks will finish, but the user 
won’t be able to see the results?

Thanks,
Ifat.

From: MinWookKim <delightw...@ssu.ac.kr<mailto:delightw...@ssu.ac.kr>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 29 March 2018 at 10:25
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat and Vitrage team.

I would like to explain more about the implementation part of the mail I sent 
last time.

The flow is as follows.

Vitrage-dashboard (action-list-panel) -> Vitrage-api -> check component

The last time I mentioned it as api-handler, it would be better to call the 
check component directly from Vitarge-api without having to use it.

I hope this helps you understand.

Thank you

Best Regards,
Minwook.

From: MinWookKim [mailto:delightw...@ssu.ac.kr]
Sent: Wednesday, March 28, 2018 11:21 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thanks for your reply. : )

This proposal is a proposal that we expect to be useful from a user perspective.

From a manager's point of view, we need an implementation that minimizes the 
overhead incurred by the proposal.

The answers to some of your questions are:


 I assume that these checks will not be implemented in Vitrage, and the 
results will not be stored in Vitrage, right? Vitrage role is to be a place 
where it is easy and intuitive for the user to execute external actions/checks.

Yes, that's right. We do not need to save it to Vitrage because we just need to 
check the results.
However, it is possible to implement the function directly in Vitrage-dashboard 
sep

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,
 
Thanks for your reply.  : )


I wrote my opinion on your comment.
 
Why do you think the request should pass through the Vitrage API? Why can’t
vitrage-dashboard call the check component directly?
 
Authentication issues:
I think the check component is a separate component based on the API.
 
In my opinion, if the check component has a separate api address from the
vitrage to receive requests from the Vitrage-dashboard, 
the Vitrage-dashboard needs to know the api address for the check
component.
 
This can result in a request / response situation open to anyone,
regardless of the authentication supported 
by openstack between the Vitrage-dashboard and the request / response
procedure of check component.
 
This is possible not only through the Vitrage-dashboard, but also with
simple commands such as curl. 
(I think it is unnecessary to implement a separate authentication system
for the check component.)
 
This problem may occur if someone knows the api address for the check
component, 
which can cause the host and VM to execute system commands.
 
what should happen if the user closes the check window before the checks
are over? I assume that the checks will finish, but the user won’t be able
to see the results?
 
If the window is closed before the check is finished, the user can not
check the result.
 
To solve this problem, I think that temporarily saving a list of recent
results is also a solution.
 
By storing temporary lists (for example, up to 10), the user can see the
previous results and think that it is also possible to empty the list by the
user.
 
how is it?
 
Thank you.
 
Best Regrads,
Minwook.
 
From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Thursday, March 29, 2018 8:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.
 
Hi Minwook,
 
Why do you think the request should pass through the Vitrage API? Why can’t
vitrage-dashboard call the check component directly?
 
And another question: what should happen if the user closes the check
window before the checks are over? I assume that the checks will finish, but
the user won’t be able to see the results?
 
Thanks,
Ifat.
 
From: MinWookKim < <mailto:delightw...@ssu.ac.kr> delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
<mailto:openstack-dev@lists.openstack.org>
openstack-dev@lists.openstack.org>
Date: Thursday, 29 March 2018 at 10:25
To: "'OpenStack Development Mailing List (not for usage questions)'" <
<mailto:openstack-dev@lists.openstack.org>
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.
 
Hello Ifat and Vitrage team.
 
I would like to explain more about the implementation part of the mail I
sent last time.
 
The flow is as follows.
 
Vitrage-dashboard (action-list-panel) -> Vitrage-api -> check component
 
The last time I mentioned it as api-handler, it would be better to call the
check component directly from Vitarge-api without having to use it.
 
I hope this helps you understand.
 
Thank you
 
Best Regards,
Minwook. 
 
From: MinWookKim [ <mailto:delightw...@ssu.ac.kr>
mailto:delightw...@ssu.ac.kr] 
Sent: Wednesday, March 28, 2018 11:21 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.
 
Hello Ifat, 
 
Thanks for your reply. : )
 
This proposal is a proposal that we expect to be useful from a user
perspective.

>From a manager's point of view, we need an implementation that minimizes
the overhead incurred by the proposal.

The answers to some of your questions are:
 
  I assume that these checks will not be implemented in Vitrage, and
the results will not be stored in Vitrage, right? Vitrage role is to be a
place where it is easy and intuitive for the user to execute external
actions/checks.
 
Yes, that's right. We do not need to save it to Vitrage because we just
need to check the results. 
However, it is possible to implement the function directly in
Vitrage-dashboard separately from Vitrage like add-action-list panel, 
but it seems that it is not enough to implement all the functions. 
If you do not mind, we will have the following flow.

1. The user requests the check action from the vitrage-dashboard
(add-action-list-panel).
2. Call the check component through the vitrage's API handler.
3. The check component executes the command and returns the result.
 
Because it is my opinion only, please tell us if there is an unnecessary
part. :)
 
  Do you expect the user to click an entity, select an action to run
(e.g. ‘P2P check’), and wait by the open panel for the results? What if the
user switches to another menu before the check is done? What if the user
asks to run an additional check in parallel? What if the user wants to see
again a previous result?

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Why do you think the request should pass through the Vitrage API? Why can’t 
vitrage-dashboard call the check component directly?

And another question: what should happen if the user closes the check window 
before the checks are over? I assume that the checks will finish, but the user 
won’t be able to see the results?

Thanks,
Ifat.

From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 29 March 2018 at 10:25
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat and Vitrage team.

I would like to explain more about the implementation part of the mail I sent 
last time.

The flow is as follows.

Vitrage-dashboard (action-list-panel) -> Vitrage-api -> check component

The last time I mentioned it as api-handler, it would be better to call the 
check component directly from Vitarge-api without having to use it.

I hope this helps you understand.

Thank you

Best Regards,
Minwook.

From: MinWookKim [mailto:delightw...@ssu.ac.kr]
Sent: Wednesday, March 28, 2018 11:21 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thanks for your reply. : )

This proposal is a proposal that we expect to be useful from a user perspective.

From a manager's point of view, we need an implementation that minimizes the 
overhead incurred by the proposal.

The answers to some of your questions are:


•   I assume that these checks will not be implemented in Vitrage, and the 
results will not be stored in Vitrage, right? Vitrage role is to be a place 
where it is easy and intuitive for the user to execute external actions/checks.

Yes, that's right. We do not need to save it to Vitrage because we just need to 
check the results.
However, it is possible to implement the function directly in Vitrage-dashboard 
separately from Vitrage like add-action-list panel,
but it seems that it is not enough to implement all the functions.
If you do not mind, we will have the following flow.

1. The user requests the check action from the vitrage-dashboard 
(add-action-list-panel).
2. Call the check component through the vitrage's API handler.
3. The check component executes the command and returns the result.

Because it is my opinion only, please tell us if there is an unnecessary part. 
:)


•   Do you expect the user to click an entity, select an action to run 
(e.g. ‘P2P check’), and wait by the open panel for the results? What if the 
user switches to another menu before the check is done? What if the user asks 
to run an additional check in parallel? What if the user wants to see again a 
previous result?


My idea was to select the task, wait for the results in an open panel, and then 
instantly see it in the panel.
If we switch to another menu before the scan is complete, we will not be able 
to see the results.
Parallel checking is a matter of fact. (This can cause excessive overhead.)
For earlier results, it may be okay to temporarily save the open panel until we 
exit the panel. We can see the previous results through the temporary saved 
results.


•   Any thoughts of what component will implement those checks? Or maybe 
these will be just scripts?

I think I implement a separate component to request it.


•   It could be nice if, as a result of an action check, a new alarm will 
be raised in Vitrage. A specific alarm with the additional details that were 
found. However, it might not be trivial to implement it. We could think about 
it as phase #2.


It is expected to be really good. It would be very useful if an Entity-Graph 
generates an alarm based on the check result.
I think that part will be able to talk in detail later.
My answer is my opinions and assumptions.
If you think my implementation is wrong, or an inefficient implementation, 
please do not hesitate to tell me.

Thanks.

Best Regards,
Minwook.
From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, March 28, 2018 2:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hi Minwook,

I think that from a user’s perspective, these are very good ideas.

I have some questions regarding the UX and the implementation, since I’m trying 
to think what could be the best way to execute such actions from Vitrage.


· I assume that these checks will not be implemented in Vitrage, and 
the results will not be stored in Vitrage, right? Vitrage role is to be a place 
where it is easy and intuitive for the user to execute external actions/checks.

· Do you expect the user to click an entity, select an action to run 
(e.g. ‘P2P check’), and 

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat and Vitrage team.
 
I would like to explain more about the implementation part of the mail I
sent last time.
 
The flow is as follows.
 
Vitrage-dashboard (action-list-panel) -> Vitrage-api -> check component
 
The last time I mentioned it as api-handler, it would be better to call the
check component directly from Vitarge-api without having to use it.
 
I hope this helps you understand.
 
Thank you
 
Best Regards,
Minwook. 
 
From: MinWookKim [mailto:delightw...@ssu.ac.kr] 
Sent: Wednesday, March 28, 2018 11:21 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.
 
Hello Ifat, 
 
Thanks for your reply. : )
 
This proposal is a proposal that we expect to be useful from a user
perspective.

>From a manager's point of view, we need an implementation that minimizes
the overhead incurred by the proposal.

The answers to some of your questions are:
 
•  I assume that these checks will not be implemented in Vitrage, and
the results will not be stored in Vitrage, right? Vitrage role is to be a
place where it is easy and intuitive for the user to execute external
actions/checks.
 
Yes, that's right. We do not need to save it to Vitrage because we just
need to check the results. 
However, it is possible to implement the function directly in
Vitrage-dashboard separately from Vitrage like add-action-list panel, 
but it seems that it is not enough to implement all the functions. 
If you do not mind, we will have the following flow.

1. The user requests the check action from the vitrage-dashboard
(add-action-list-panel).
2. Call the check component through the vitrage's API handler.
3. The check component executes the command and returns the result.
 
Because it is my opinion only, please tell us if there is an unnecessary
part. :)
 
•  Do you expect the user to click an entity, select an action to run
(e.g. ‘P2P check’), and wait by the open panel for the results? What if the
user switches to another menu before the check is done? What if the user
asks to run an additional check in parallel? What if the user wants to see
again a previous result?
 
My idea was to select the task, wait for the results in an open panel, and
then instantly see it in the panel. 
If we switch to another menu before the scan is complete, we will not be
able to see the results.
Parallel checking is a matter of fact. (This can cause excessive overhead.)
For earlier results, it may be okay to temporarily save the open panel
until we exit the panel. We can see the previous results through the
temporary saved results.
 
•  Any thoughts of what component will implement those checks? Or maybe
these will be just scripts?
 
I think I implement a separate component to request it.
 
•   It could be nice if, as a result of an action check, a new alarm
will be raised in Vitrage. A specific alarm with the additional details that
were found. However, it might not be trivial to implement it. We could think
about it as phase #2.
 
It is expected to be really good. It would be very useful if an
Entity-Graph generates an alarm based on the check result.
I think that part will be able to talk in detail later.
My answer is my opinions and assumptions.
If you think my implementation is wrong, or an inefficient implementation,
please do not hesitate to tell me.
 
Thanks.
 
Best Regards,
Minwook. 
From: Afek, Ifat (Nokia - IL/Kfar Sava) [ <mailto:ifat.a...@nokia.com>
mailto:ifat.a...@nokia.com] 
Sent: Wednesday, March 28, 2018 2:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.
 
Hi Minwook,
 
I think that from a user’s perspective, these are very good ideas.
 
I have some questions regarding the UX and the implementation, since I’m
trying to think what could be the best way to execute such actions from
Vitrage.
 
* I assume that these checks will not be implemented in Vitrage,
and the results will not be stored in Vitrage, right? Vitrage role is to be
a place where it is easy and intuitive for the user to execute external
actions/checks.
* Do you expect the user to click an entity, select an action to
run (e.g. ‘P2P check’), and wait by the open panel for the results? What if
the user switches to another menu before the check is done? What if the user
asks to run an additional check in parallel? What if the user wants to see
again a previous result?
* Any thoughts of what component will implement those checks? Or
maybe these will be just scripts? 
* It could be nice if, as a result of an action check, a new alarm
will be raised in Vitrage. A specific alarm with the additional details that
were found. However, it might not be trivial to implement it. We could think
about it as phase #2.
 
Best Regards,
Ifat
 
 
From: MinWookKim < <mailto:delightw...@ssu.ac.kr> delightw...@ssu.ac.kr>
Reply-To: "Op

[openstack-dev] [vitrage] Next two IRC meetings are canceled

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Most of Vitrage developers will not be available today and next Wednesday, so 
we’ll skip the next two IRC meetings.
We will meet again on Wednesday, April 11.

Thanks,
Ifat

__
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

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat, 

 

Thanks for your reply. : )

 

This proposal is a proposal that we expect to be useful from a user
perspective.

>From a manager's point of view, we need an implementation that minimizes
the overhead incurred by the proposal.

The answers to some of your questions are:

 

•  I assume that these checks will not be implemented in Vitrage, and
the results will not be stored in Vitrage, right? Vitrage role is to be a
place where it is easy and intuitive for the user to execute external
actions/checks.

 

Yes, that's right. We do not need to save it to Vitrage because we just
need to check the results. 

However, it is possible to implement the function directly in
Vitrage-dashboard separately from Vitrage like add-action-list panel, 

but it seems that it is not enough to implement all the functions. 

If you do not mind, we will have the following flow.


1. The user requests the check action from the vitrage-dashboard
(add-action-list-panel).
2. Call the check component through the vitrage's API handler.
3. The check component executes the command and returns the result.

 

Because it is my opinion only, please tell us if there is an unnecessary
part. :)

 

•  Do you expect the user to click an entity, select an action to run
(e.g. ‘P2P check’), and wait by the open panel for the results? What if the
user switches to another menu before the check is done? What if the user
asks to run an additional check in parallel? What if the user wants to see
again a previous result?

 

My idea was to select the task, wait for the results in an open panel, and
then instantly see it in the panel. 

If we switch to another menu before the scan is complete, we will not be
able to see the results.
Parallel checking is a matter of fact. (This can cause excessive overhead.)
For earlier results, it may be okay to temporarily save the open panel
until we exit the panel. We can see the previous results through the
temporary saved results.

 

•  Any thoughts of what component will implement those checks? Or maybe
these will be just scripts?

 

I think I implement a separate component to request it.

 

•  It could be nice if, as a result of an action check, a new alarm
will be raised in Vitrage. A specific alarm with the additional details that
were found. However, it might not be trivial to implement it. We could think
about it as phase #2.

 

It is expected to be really good. It would be very useful if an
Entity-Graph generates an alarm based on the check result.

I think that part will be able to talk in detail later.

My answer is my opinions and assumptions.

If you think my implementation is wrong, or an inefficient implementation,
please do not hesitate to tell me.

 

Thanks.

 

Best Regards,

Minwook. 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, March 28, 2018 2:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I think that from a user’s perspective, these are very good ideas.

 

I have some questions regarding the UX and the implementation, since I’m
trying to think what could be the best way to execute such actions from
Vitrage.

 

* I assume that these checks will not be implemented in Vitrage,
and the results will not be stored in Vitrage, right? Vitrage role is to be
a place where it is easy and intuitive for the user to execute external
actions/checks.

* Do you expect the user to click an entity, select an action to
run (e.g. ‘P2P check’), and wait by the open panel for the results? What if
the user switches to another menu before the check is done? What if the user
asks to run an additional check in parallel? What if the user wants to see
again a previous result?

* Any thoughts of what component will implement those checks? Or
maybe these will be just scripts? 

* It could be nice if, as a result of an action check, a new alarm
will be raised in Vitrage. A specific alarm with the additional details that
were found. However, it might not be trivial to implement it. We could think
about it as phase #2.

 

Best Regards,

Ifat

 

 

From: MinWookKim <delightw...@ssu.ac.kr <mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 27 March 2018 at 14:45
To: "openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> "
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org> >
Subject: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Vitrage team.

 

I am currently working on the Vitrage-Dashboard proposal for the ‘Add
action list panel for entity click action’.

(https://review.openstack.org/#/c/531141/)

 

I would like to m

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

I think that from a user’s perspective, these are very good ideas.

I have some questions regarding the UX and the implementation, since I’m trying 
to think what could be the best way to execute such actions from Vitrage.


· I assume that these checks will not be implemented in Vitrage, and 
the results will not be stored in Vitrage, right? Vitrage role is to be a place 
where it is easy and intuitive for the user to execute external actions/checks.

· Do you expect the user to click an entity, select an action to run 
(e.g. ‘P2P check’), and wait by the open panel for the results? What if the 
user switches to another menu before the check is done? What if the user asks 
to run an additional check in parallel? What if the user wants to see again a 
previous result?

· Any thoughts of what component will implement those checks? Or maybe 
these will be just scripts?

· It could be nice if, as a result of an action check, a new alarm will 
be raised in Vitrage. A specific alarm with the additional details that were 
found. However, it might not be trivial to implement it. We could think about 
it as phase #2.

Best Regards,
Ifat


From: MinWookKim <delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 27 March 2018 at 14:45
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Vitrage team.

I am currently working on the Vitrage-Dashboard proposal for the ‘Add action 
list panel for entity click action’.
(https://review.openstack.org/#/c/531141/)

I would like to make a new proposal based on the action list panel mentioned 
above.

The new proposal is to provide multidimensional analysis capabilities in 
several entities that make up the infrastructure in the entity graph.

Vitrage's entity-graph allows us to efficiently monitor alarms from various 
monitoring tools.

In the current state, when there is a problem with the VM and Host, or when we 
want to check the status, we need to access the console individually for each 
VM and Host.

This situation causes unnecessary behavior when the number of VMs and hosts 
increases.

My new suggestion is that if we have a large number of vm and host, we do not 
need to directly connect to each VM, host console to enter the system command.

Instead, we can send a system command to VM and hosts in the cloud through this 
proposal. It is only checking results.

I have written some use-cases for an efficient explanation of the function.

From an implementation perspective, the goals of the proposal are:


1. To execute commands without installing any Agent / Client that can cause 
load on VM, Host.

2. I want to provide a simple UI so that users or administrators can get the 
desired information to multiple VMs and hosts.

3. I want to be able to grasp the results at a glance.

4. I want to implement a component that can support many additional scenarios 
in plug-in format.

I would be happy if you could comment on the proposal or ask questions.

Thanks.

Best Regards,
Minwook.
__
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

Re: [openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

[Afek, Ifat (Nokia - IL/Kfar Sava)]

I added Dong Wenjuan to the list of core contributors.
Welcome ☺

From: Eyal B <eya...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 21 March 2018 at 16:57
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

+2

On 21 March 2018 at 16:37, Afek, Ifat (Nokia - IL/Kfar Sava) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi,

I would like to nominate Dong Wenjuan for Vitrage core.
Wenjuan has been contributing to Vitrage for a long time, since Newton version. 
She implemented several important features and has a deep knowledge of Vitrage 
architecture. I’m sure she can be a great addition to our team.

Thanks,
Ifat.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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

Re: [openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

[Eyal B]

+2

On 21 March 2018 at 16:37, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> I would like to nominate Dong Wenjuan for Vitrage core.
>
> Wenjuan has been contributing to Vitrage for a long time, since Newton
> version. She implemented several important features and has a deep
> knowledge of Vitrage architecture. I’m sure she can be a great addition to
> our team.
>
>
>
> Thanks,
>
> Ifat.
>
>
>
> __
> 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
>
>
__
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

[openstack-dev] [vitrage] Nominating Dong Wenjuan for Vitrage core

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I would like to nominate Dong Wenjuan for Vitrage core.
Wenjuan has been contributing to Vitrage for a long time, since Newton version. 
She implemented several important features and has a deep knowledge of Vitrage 
architecture. I’m sure she can be a great addition to our team.

Thanks,
Ifat.

__
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

[openstack-dev] [vitrage] alarm and resource equivalence

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Since we need to design these days both alarm equivalence/merge [1] and 
resource equivalence/merge features, I thought it might be a good idea to start 
with a use cases document. Let’s agree on the requirements, and then see if we 
can come up with a design that matches both cases. I pushed the first draft for 
the use cases document [2], and I’ll be happy to get your comments.

[1] https://review.openstack.org/#/c/547931 
[2] https://review.openstack.org/#/c/550534 

Thanks, 
Ifat.



__
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

[openstack-dev] [vitrage] No IRC meeting today

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

We will not hold the weekly IRC meeting today due to the PTG discussions.
We will meet again next week, March 6th.

BR,
Ifat

__
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

[openstack-dev] [vitrage][ptg] Vitrage PTG agenda

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Vitrage PTG discussions will start today at 9:00 Dublin time. You are all 
welcome to join. 
We will hold the discussions on webex, so you can join remotely as well.

PTG etherpad:
https://etherpad.openstack.org/p/vitrage-ptg-rocky 

See you soon,
Ifat



__
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

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

Unfortunately I can’t figure out from the log what went wrong. It seems like 
the ‘up’ alarms are ignored. Two things that I would try next:

· Try calling an event with ‘status’:’up’ and see if it works. This is 
working for sure in my environment

· I suspect that the problem is somewhere in 
AlarmDriverBase._filter_and_cache_alarms(). Basically it should search the old 
alarm in the cache and update it. Try to add many debug messages so we could 
see the cache, the new alarm and the old alarm.

Let me know if it helped.
Ifat.

From: Paul Vaduva <paul.vad...@enea.com>
Date: Wednesday, 21 February 2018 at 19:11
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "OpenStack 
Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: RE: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Ifat,

Link to cuted log version
https://hastebin.com/upokifinuq.py

Plus full graph.log attached plus code for driver.py with Logging modifications

Thanks,
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 21, 2018 6:18 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I suggest that you do the following:

· Add a LOG message at the end of _get_alarms to print all alarms that 
are returned by this function

· Restart vitrage-graph and send me its log. I’d like to see if there 
is any difference between the alarm that is raised and the alarm that is 
deleted.

Thanks,
Ifat.

From: Paul Vaduva <paul.vad...@enea.com<mailto:paul.vad...@enea.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, 21 February 2018 at 16:30
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generatio

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

I suggest that you do the following:

· Add a LOG message at the end of _get_alarms to print all alarms that 
are returned by this function

· Restart vitrage-graph and send me its log. I’d like to see if there 
is any difference between the alarm that is raised and the alarm that is 
deleted.

Thanks,
Ifat.

From: Paul Vaduva <paul.vad...@enea.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 21 February 2018 at 16:30
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasourc

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Sorry forgot to add you.

From: Paul Vaduva
Sent: Wednesday, February 21, 2018 4:31 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: RE: [openstack-dev] [vitrage] Vitrage alarm processing behavior

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=Pe0SmnJrux3qg2aeVKwciP-we0PY0bk3JoTO_20fQHQ70cIoAgpMPXrk8JuN_BWqpqnpygQerGyzW2Snm5KfUQ7Y-INhOKG5eybo-thEBodvAhGSFpyXWQxPXS0Auc9aF0vGy2Ea4hrWfL6eeD0bQycBJN8lTLZnuIQx59ZeULyqstlxVBL34dcnQOFQf-5nS76n_X9owe_iNZrV57fmTrGKDogeMocpOJwlz9vnzzCDaL7RjjqCRLcbAxwkyRas3lujR6oZKt9NK1NBb-hb3uc721qSI6SR8SVN6zZGjQE>
[2] 
https://github.com/openstack/vitrage/tree/master/v

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Ciprian Barbu <ciprian.ba...@enea.com<mailto:ciprian.ba...@enea.com>>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=Pe0SmnJrux3qg2aeVKwciP-we0PY0bk3JoTO_20fQHQ70cIoAgpMPXrk8JuN_BWqpqnpygQerGyzW2Snm5KfUQ7Y-INhOKG5eybo-thEBodvAhGSFpyXWQxPXS0Auc9aF0vGy2Ea4hrWfL6eeD0bQycBJN8lTLZnuIQx59ZeULyqstlxVBL34dcnQOFQf-5nS76n_X9owe_iNZrV57fmTrGKDogeMocpOJwlz9vnzzCDaL7RjjqCRLcbAxwkyRas3lujR6oZKt9NK1NBb-hb3uc721qSI6SR8SVN6zZGjQE>
[2] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=uGgIuECLH17WmCqispfyornk-y9i4E2eyyvxC5fH2sepif7vNt0e_Op9ifHIcOuZLWy4fzJMsbItzfWpk5qNeYW2O3iEr5sPuXnguxKSRm6yrD12oGtjjJibDR7oVJnkQSNtu5caCM1BoguJiXBL7WisodfHGVdbYJDe2W2m11dc3ZmARXYI1FlmVWOPQiAGlzNtUgcQ_wpYwHtTJJaur8wiS415nr2oRHwU4C9hawW9HWktVVEH877WI_P1xf3VI1PjGVf75imEW-bHo3lAtCIAv4hWKcrxtHdL48oP7kQ>
[3] 
https://docs.op

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=Pe0SmnJrux3qg2aeVKwciP-we0PY0bk3JoTO_20fQHQ70cIoAgpMPXrk8JuN_BWqpqnpygQerGyzW2Snm5KfUQ7Y-INhOKG5eybo-thEBodvAhGSFpyXWQxPXS0Auc9aF0vGy2Ea4hrWfL6eeD0bQycBJN8lTLZnuIQx59ZeULyqstlxVBL34dcnQOFQf-5nS76n_X9owe_iNZrV57fmTrGKDogeMocpOJwlz9vnzzCDaL7RjjqCRLcbAxwkyRas3lujR6oZKt9NK1NBb-hb3uc721qSI6SR8SVN6zZGjQE>
[2] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=uGgIuECLH17WmCqispfyornk-y9i4E2eyyvxC5fH2sepif7vNt0e_Op9ifHIcOuZLWy4fzJMsbItzfWpk5qNeYW2O3iEr5sPuXnguxKSRm6yrD12oGtjjJibDR7oVJnkQSNtu5caCM1BoguJiXBL7WisodfHGVdbYJDe2W2m11dc3ZmARXYI1FlmVWOPQiAGlzNtUgcQ_wpYwHtTJJaur8wiS415nr2oRHwU4C9hawW9HWktVVEH877WI_P1xf3VI1PjGVf75imEW-bHo3lAtCIAv4hWKcrxtHdL48oP7kQ>
[3] 
https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html<https://url10.mailanyone.net/v1/?m=1ejTL3-0003ZV-4n=57e1b682=A08vm8gwOUlRCFuV_ZDNRKrFdo7lGQmqtrZE-ZXEB6yLzcanUHFW1Aue5PnhXvrALgd0apyK5SAU9-PPc5Pqi5uod_I2JAHONug3ILQ9e3RvoKWyoYcuehJzRa3bqH3g_r5GQnKIRRNnYccSg6T4wkA-Wl6PHZ7KXq7cYp9zY7Fhz2jCK_zTUNBGJvLR2W_bqwPdTe2iyetPXPa0N_JrF38KrkUOVppDYgfi4_onM9N6QUUEECArxlYPl-T3xDM5cMSrTf9iE38OJrg_nKG8Fkwr7rAV5L8tAEZ5vGMDQxc>


Best Regards,
Ifat.


From: Paul Vaduva <pau

[openstack-dev] [vitrage] Tagged Vitrage release candidates and created stable/queens branches

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I tagged the following release candidates for Vitrage:

vitrage 2.1.0
vitrage-dashboard 1.4.1
python-vitrageclient 2.0.0 (already tagged)

All these repositories now have stable/queens branches, so the master can be 
used for Rocky development.

Thanks,
Ifat.


__
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

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume
[2] https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix
[3] 
https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html


Best Regards,
Ifat.


From: Paul Vaduva <paul.vad...@enea.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 7 February 2018 at 15:50
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: Ciprian Barbu <ciprian.ba...@enea.com>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Ifat,

Yes I’ve checked the 1.3.1 refers to a deb package (python-vitrage) version 
built by us, so the git tag used to build that deb is 1.3.0.
But I also backported doctor datasource from vitreage git master branch.

I also noticed that when I configure snapshots_interval=10 I also get this 
exception in
/var/log/vitrage/graph.log around the time the alarms disapear.
https://hastebin.com/ukisajojef.sql

I've cherry picked your before mentioned change and the alarm that came from 
event is now persistent and the exception is gone.
So it was a bug.
I understand that for doctor datasources I need to have events for raising the 
alarm and also for clearing it is that correct?


Best Regards,
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 1:24 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


[1] 
https://review.openstack.org/#/c/524228<https://url10.mailanyone.net/v1/?m=1ejNt4-0001fR-4I=57e1b682=LqJB68i5VuuaUnZ6iOIMHVhcsHMatfhcTwtLpAT-Rn5UZ3qnX4tq4XOTjYR1XqQIDRQGrqGMwZI31cnT-bEHTFX95wRD-iENXse8JBDHIyv8iJUD7RiwDp74HqNHBFZ-BybLQgQ6-sVcf62n2ogMk31b-Sp0xUJZXxH_0q2Iu-4Hodt4gxhKuFMTT2breh42c7OT5kdHzPJThKClzSEBQ2NWkNTCy112gxlapjMCVxSNQ9nsLg4f0XyJaAVUnAHO>


Best Regards,
Ifat.


From: Paul Vaduva <paul.vad...@enea.com<mailto:paul.vad...@enea.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, 7 February 2018 at 11:58
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,do

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Ifat,

Yes I’ve checked the 1.3.1 refers to a deb package (python-vitrage) version 
built by us, so the git tag used to build that deb is 1.3.0.
But I also backported doctor datasource from vitreage git master branch.

I also noticed that when I configure snapshots_interval=10 I also get this 
exception in
/var/log/vitrage/graph.log around the time the alarms disapear.
https://hastebin.com/ukisajojef.sql

I've cherry picked your before mentioned change and the alarm that came from 
event is now persistent and the exception is gone.
So it was a bug.
I understand that for doctor datasources I need to have events for raising the 
alarm and also for clearing it is that correct?


Best Regards,
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 1:24 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


[1] 
https://review.openstack.org/#/c/524228<https://url10.mailanyone.net/v1/?m=1ejNt4-0001fR-4I=57e1b682=LqJB68i5VuuaUnZ6iOIMHVhcsHMatfhcTwtLpAT-Rn5UZ3qnX4tq4XOTjYR1XqQIDRQGrqGMwZI31cnT-bEHTFX95wRD-iENXse8JBDHIyv8iJUD7RiwDp74HqNHBFZ-BybLQgQ6-sVcf62n2ogMk31b-Sp0xUJZXxH_0q2Iu-4Hodt4gxhKuFMTT2breh42c7OT5kdHzPJThKClzSEBQ2NWkNTCy112gxlapjMCVxSNQ9nsLg4f0XyJaAVUnAHO>


Best Regards,
Ifat.


From: Paul Vaduva <paul.vad...@enea.com<mailto:paul.vad...@enea.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, 7 February 2018 at 11:58
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

Best Regards,
Paul Vaduva
__
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

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


[1] https://review.openstack.org/#/c/524228


Best Regards,
Ifat.


From: Paul Vaduva <paul.vad...@enea.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 7 February 2018 at 11:58
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

Best Regards,
Paul Vaduva
__
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

[openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

Best Regards,
Paul Vaduva
__
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

Re: [openstack-dev] [vitrage][ptl] PTL candidacy for Rocky

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Sorry for the copy problem in the previous email… 
Ifat


On 01/02/2018, 15:24, "Afek, Ifat (Nokia - IL/Kfar Sava)"  
wrote:

Hi all,

I would like to announce my candidacy to continue as Vitrage PTL for the 
Rocky
release.

I’ve been the PTL of Vitrage since the day it started, in the Mitaka 
release.
I think we have made an amazing journey, and we now have a mature, stable 
and
well known project. During the Queens cycle our community has grown, and we
managed to complete many important tasks, like:

* API for template add and template delete
* Enhancements in the templates language
* API for registering web hooks on Vitrage alarms
* Performance enhancements, mostly around parallel evaluation of the 
templates

I believe that these new features will greatly improve the usability of
Vitrage.

As for the Rocky cycle, I think we have many challenging tasks in our road 
map.
We have a great team which combines very experienced contributors and
enthusiastic newcomers, and we are always happy to welcome new contributors.

The issues that I think we should focus on are:

* Alarm and resource aggregation
* Proactive RCA (Root Cause Analysis)
* RCA history
* Kubernetes Support
* API enhancements, mostly around the topology queries

I look forward to working with you all in the coming cycle.

Thanks,
Ifat.



__
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

[openstack-dev] [vitrage][ptl] PTL candidacy for Rocky

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi all,

I would like to announce my candidacy to continue as Vitrage PTL for the Rocky
release.

I’ve been the PTL of Vitrage since the day it started, in the Mitaka release.
I think we have made an amazing journey, and we now have a mature, stable and
well known project. During the Queens cycle our community has grown, and we
managed to complete many important tasks, like:

* API for template add and template delete
* Enhancements in the templates language
* API for registering web hooks on Vitrage alarms
* Performance enhancements, mostly around parallel evaluation of the templates

I believe that these new features will greatly improve the usability of
Vitrage.

As for the Rocky cycle, I think we have many challenging tasks in our road map.
We have a great team which combines very experienced contributors and
enthusiastic newcomers, and we are always happy to welcome new contributors.

The issues that I think we should focus on are:

* Alarm and resource aggregation
* Proactive RCA (Root Cause Analysis)
* RCA history
* Kubernetes Support
* API enhancements, mostly around the topology queries

Hi all,

I would like to announce my candidacy to continue as Vitrage PTL for the Rocky
release.

I’ve been the PTL of Vitrage since the day it started, in the Mitaka release.
I think we have made an amazing journey, and we now have a mature, stable and
well known project. During the Queens cycle our community has grown, and we
managed to complete many important tasks, like:

* API for template add and template delete
* Enhancements in the templates language
* API for registering web hooks on Vitrage alarms
* Performance enhancements, mostly around parallel evaluation of the templates

I believe that these new features will greatly improve the usability of
Vitrage.

As for the Rocky cycle, I think we have many challenging tasks in our road map.
We have a great team which combines very experienced contributors and
enthusiastic newcomers, and we are always happy to welcome new contributors.

The issues that I think we should focus on are:

* Alarm and resource aggregation
* Proactive RCA (Root Cause Analysis)
* RCA history
* Kubernetes Support
* API enhancements, mostly around the topology queries

I look forward to working with you all in the coming cycle.

Thanks,
Ifat.


__
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

[openstack-dev] [vitrage] Vitrage templates are now loaded using a new API

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

A new API for Vitrage template add and template delete was added this week.

As part of this change, Vitrage templates are now stored in a database and are 
no longer read from the file system. In case you are using templates, make sure 
to call the new API and add them to Vitrage once you get the latest version.

More details can be found on the spec [1] and on Vitrage API [2] and CLI [3] 
documentation.

Thanks,
Ifat.

[1] 
https://specs.openstack.org/openstack/vitrage-specs/specs/queens/implemented/template-CRUD.html
 
[2] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html 
[3] https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html 
 



__
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

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Afek, Ifat (Nokia - IL/Kfar Sava)]

From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
Date: Thursday, 11 January 2018 at 10:52

I have almost understood it thanks to your explanation.

[Ifat] I liked the “almost” ;-)

The confusion is mainly caused by the naming. I guess the main reason is that 
the scope evolves but the naming is not updated with it.

For example
1.  `vitrage_aggregated_state` actually applies for both resource state and 
alarm severity as defined in `value_properties`. So `vitrage_aggregated_values` 
could be a better name.
[Ifat] For alarms we use ‘vitrage_aggregated_severity’
2.  For data source in static configuration, we may use `static.yaml` as a 
fallback. The name `default.yaml` will mislead user that it should be applied 
to data source configured in "types" but without a values configuration.
[Ifat] We should decide whether we want the default values to apply also to 
“real” datasources. I think the risk is that people who write a new datasource 
will forget to add the values yaml file, and will believe that everything works 
fine with the default. Then, upon a specific failure (that doesn’t happen 
often) they will get UNDEFINED status. On the other hand, if they always get 
UNDEFINED, they will remember to add the correct yaml file.
3.  The UNDEFINED value is named UNDEFINED_DATASOURCE = "undefined 
datasource", it is not a consistent type of severity and state enumeration.
[Ifat] I didn’t understand this comment.
4.  The behavior for data source defined in static without values 
configuration and data source defined in "types" without values configuration 
are inconsistent. The former will fallback to `default.yaml` but the latter 
will lead to undefined value.
[Ifat] See my answer to #2.
I know it is there for historical reasons and current developers may already 
get used to it, but it gives new contributors too many surprises.

What do you think? Shall we amend them?

On Tue, Jan 9, 2018 at 11:29 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi,

I agree that the code is confusing…

This is part of a change that was made in order to support default states for 
static entities. For example, in the static configuration yaml file you can add 
entities of types ‘switch’ and ‘br-ex’. In the past, in order to support states 
for these new types, you needed to add switch.yaml and br-ex.yaml under 
/etc/vitrage/datasources_values, which you would most likely copy from 
another datasource. Now, we have under /etc/vitrage/datasources_values a 
default.yaml file that is used for all static entities.

Back to the code, I believe this is the logic:


• If the datasource is part of ‘types’ (as defined in vitrage.conf) and 
has states configuration – use it. This is the normal behavior.

• If the datasource is not part of ‘types’, we understand that it was 
defined in a static configuration file. Use the default states configuration. I 
assume that it is somehow handled in the first part of the if statement (I’m 
not so familiar with that code)

• If neither is true – it means that the datasource is “real” and not 
static, and was defined in vitrage.conf types. And it also means that its 
states configuration is missing, so the state is UNDEFINED.

And to your questions:

1.  the data source is not defined -> the default states should be used
2.  data source defined but state config not exist -> UNDEFINED state
3.  data source defined, state config exist but the state is not found. -> 
I believe that somewhere in the first part of the if statement you will get 
UNDEFINED


Hope that’s more clear now. It might be a good idea to add some comments to 
that function…

Best Regards,
Ifat.


From: "Yujun Zhang (ZTE)" 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 9 January 2018 at 8:34
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote:
Hi root causers

I have been inspecting the code about aggregated state recently and have a 
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured data 
source, how do we apply the aggregation rules? It seems this is handled in else 
clause.


   

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

I have almost understood it thanks to your explanation.

The confusion is mainly caused by the naming. I guess the main reason is
that the scope evolves but the naming is not updated with it.

For example

   1. `vitrage_aggregated_state` actually applies for both resource state
   and alarm severity as defined in `value_properties`. So
   `vitrage_aggregated_values` could be a better name.
   2. For data source in static configuration, we may use `static.yaml` as
   a fallback. The name `default.yaml` will mislead user that it should be
   applied to data source configured in "types" but without a values
   configuration.
   3. The UNDEFINED value is named UNDEFINED_DATASOURCE = "undefined
   datasource", it is not a consistent type of severity and state enumeration.
   4. The behavior for data source defined in static without values
   configuration and data source defined in "types" without values
   configuration are inconsistent. The former will fallback to `default.yaml`
   but the latter will lead to undefined value.

I know it is there for historical reasons and current developers may
already get used to it, but it gives new contributors too many surprises.

What do you think? Shall we amend them?

On Tue, Jan 9, 2018 at 11:29 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> I agree that the code is confusing…
>
>
>
> This is part of a change that was made in order to support default states
> for static entities. For example, in the static configuration yaml file you
> can add entities of types ‘switch’ and ‘br-ex’. In the past, in order to
> support states for these new types, you needed to add switch.yaml and
> br-ex.yaml under /etc/vitrage/datasources_values, which you would most
> likely copy from another datasource. Now, we have under
> /etc/vitrage/datasources_values a default.yaml file that is used for all
> static entities.
>
>
>
> Back to the code, I believe this is the logic:
>
>
>
> · If the datasource is part of ‘types’ (as defined in
> vitrage.conf) and has states configuration – use it. This is the normal
> behavior.
>
> · If the datasource is not part of ‘types’, we understand that it
> was defined in a static configuration file. Use the default states
> configuration. I assume that it is somehow handled in the first part of the
> if statement (I’m not so familiar with that code)
>
> · If neither is true – it means that the datasource is “real” and
> not static, and was defined in vitrage.conf types. And it also means that
> its states configuration is missing, so the state is UNDEFINED.
>
>
>
> And to your questions:
>
>
>
>1. the data source is not defined -> the default states should be used
>2. data source defined but state config not exist -> UNDEFINED state
>3. data source defined, state config exist but the state is not found.
>-> I believe that somewhere in the first part of the if statement you will
>get UNDEFINED
>
>
>
>
>
> Hope that’s more clear now. It might be a good idea to add some comments
> to that function…
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *"Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Tuesday, 9 January 2018 at 8:34
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] rules in
> vitrage_aggregated_state()
>
>
>
> Forgot to paste the link to the related code:
>
>
>
>
> https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61
>
>
>
>
>
>
>
> On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
> wrote:
>
> Hi root causers
>
>
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
>
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
>
>
> if datasource_name in self.datasources_state_confs or \
>
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
>
> self.category_normalizer[vitrage_category].set_aggregated_value(
>
> new_vertex, self.UNDEFINED_DATASOURCE)
>
> self.category_normalizer[vitrage_category].set_operat

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I agree that the code is confusing…

This is part of a change that was made in order to support default states for 
static entities. For example, in the static configuration yaml file you can add 
entities of types ‘switch’ and ‘br-ex’. In the past, in order to support states 
for these new types, you needed to add switch.yaml and br-ex.yaml under 
/etc/vitrage/datasources_values, which you would most likely copy from 
another datasource. Now, we have under /etc/vitrage/datasources_values a 
default.yaml file that is used for all static entities.

Back to the code, I believe this is the logic:


· If the datasource is part of ‘types’ (as defined in vitrage.conf) and 
has states configuration – use it. This is the normal behavior.

· If the datasource is not part of ‘types’, we understand that it was 
defined in a static configuration file. Use the default states configuration. I 
assume that it is somehow handled in the first part of the if statement (I’m 
not so familiar with that code)

· If neither is true – it means that the datasource is “real” and not 
static, and was defined in vitrage.conf types. And it also means that its 
states configuration is missing, so the state is UNDEFINED.

And to your questions:


  1.  the data source is not defined -> the default states should be used
  2.  data source defined but state config not exist -> UNDEFINED state
  3.  data source defined, state config exist but the state is not found. -> I 
believe that somewhere in the first part of the if statement you will get 
UNDEFINED


Hope that’s more clear now. It might be a good idea to add some comments to 
that function…

Best Regards,
Ifat.


From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 9 January 2018 at 8:34
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote:
Hi root causers

I have been inspecting the code about aggregated state recently and have a 
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured data 
source, how do we apply the aggregation rules? It seems this is handled in else 
clause.


if datasource_name in self.datasources_state_confs or \

datasource_name not in self.conf.datasources.types:
...

else:

self.category_normalizer[vitrage_category].set_aggregated_value(

new_vertex, self.UNDEFINED_DATASOURCE)

self.category_normalizer[vitrage_category].set_operational_value(

new_vertex, self.UNDEFINED_DATASOURCE)

There are some test case describing the expected behavior. But I couldn't 
understand the design philosophy behind it. What is expected when

1.   the data source is not defined

2.   data source defined but state config not exist

3.   data source defined, state config exist but the state is not found.

Could somebody shed some light on it?




--
Yujun Zhang


--
Yujun Zhang
__
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

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
wrote:

> Hi root causers
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
> if datasource_name in self.datasources_state_confs or \
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
> self.category_normalizer[vitrage_category].set_aggregated_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
> self.category_normalizer[vitrage_category].set_operational_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
>
>
> There are some test case describing the expected behavior. But I couldn't 
> understand the design philosophy behind it. What is expected when
>
>1. the data source is not defined
>2. data source defined but state config not exist
>3. data source defined, state config exist but the state is not found.
>
> Could somebody shed some light on it?
>
>
>
> --
> Yujun Zhang
>


-- 
Yujun Zhang
__
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

[openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Hi root causers

I have been inspecting the code about aggregated state recently and have a
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured
data source, how do we apply the aggregation rules? It seems this is
handled in else clause.

if datasource_name in self.datasources_state_confs or \
datasource_name *not* in self.conf.datasources.types:
  ...

else:
self.category_normalizer[vitrage_category].set_aggregated_value(
new_vertex, self.UNDEFINED_DATASOURCE)
self.category_normalizer[vitrage_category].set_operational_value(
new_vertex, self.UNDEFINED_DATASOURCE)


There are some test case describing the expected behavior. But I
couldn't understand the design philosophy behind it. What is expected
when

   1. the data source is not defined
   2. data source defined but state config not exist
   3. data source defined, state config exist but the state is not found.

Could somebody shed some light on it?



-- 
Yujun Zhang
__
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

[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting on the coming Wednesday, Dec 27th, is canceled.

Thanks,
Ifat

__
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

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Ok, makes sense.

Regarding the vitrage_alarm_type: it will be usable only if there are a few 
alarm types that are used by most datasources. Otherwise it might be just as 
verbose as the name, IMO.

Anyway, you are welcome to propose a blueprint so we can discuss all details 
there.

Best Regards,
Ifat.

From: "Waines, Greg" <greg.wai...@windriver.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 4 December 2017 at 17:23
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

I am thinking that alarm suppression would be per-tenant.

Yeah i am liking the second suggestion, as well, wrt specification of 
suppressed alarms to be based on { vitrage_type & ‘regexp’ }.

Only other reason for introducing vitrage_alarm_type property is perhaps a 
‘usability’ type reason
i.e. it provides perhaps an easier / quicker indication of the general type of 
alarm (e.g. port-failure, host-failure, ntp-server-down, 
remote-log-server-down, ...) when scanning an alarm list, rather than having to 
read the sometimes verbose ‘name’ (description) field of the alarm.
But i realize it would be difficult to enforce / manage the usage of this field.
This is a lower priority item for me.

Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Monday, December 4, 2017 at 9:32 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines <greg.wai...@windriver.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irreleva

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

[Waines, Greg]

I am thinking that alarm suppression would be per-tenant.

Yeah i am liking the second suggestion, as well, wrt specification of 
suppressed alarms to be based on { vitrage_type & ‘regexp’ }.

Only other reason for introducing vitrage_alarm_type property is perhaps a 
‘usability’ type reason
i.e. it provides perhaps an easier / quicker indication of the general type of 
alarm (e.g. port-failure, host-failure, ntp-server-down, 
remote-log-server-down, ...) when scanning an alarm list, rather than having to 
read the sometimes verbose ‘name’ (description) field of the alarm.
But i realize it would be difficult to enforce / manage the usage of this field.
This is a lower priority item for me.

Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Monday, December 4, 2017 at 9:32 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines <greg.wai...@windriver.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
   

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Greg,

First, I think that supporting alarm suppression in Vitrage is a very good idea.

One question that I have is: I understand that you plan to support it both in 
the UI and in the CLI. Do you want to the suppression to be per-user? 
per-tenant? global?

Regarding adding vitrage_alarm_type, my main concern is how the different 
datasources will fill this information. A monitor like Zabbix can have a lot of 
different alarms, and we will have to find a way to map them to the different 
alarm types. Aodh could also have its own alarm types, etc. I believe that some 
monitors will not use this property at all, which will cause:

· No way to suppress some of the alarms by vitrage_alarm_type

· Empty column in Vitrage alarms list

I think that your second suggestion, of the vitrage_type and regex, could work 
better. Is there any other reason to add the vitrage_alarm_type property, other 
than for suppression purposes?

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms 
by type and/or resource in Vitrage

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
o   could be an optional field
o   but we’d display in the alarm list
o   and we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

o   could use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines <greg.wai...@windriver.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

o   name (string) - the alarm description

o   vitrage_resource_type (enum) - e.g. nova.instance, nova.host, port, ...

o   vitrage_resource_id (uuid) - resource instance

o   vitrage_aggregated_severity

o   vitrage_operational_severity

o   update_timestamp

·

· there definitely is a specific resource identifier in order to be 
able to suppress alarms from a particular resource

·

· BUT there doesn’t seem like there is a general alarm type field
i.e. that would classify the type of problem that’s occurring
e.g.

o   communication failure with compute host

o   loss-of-signal on port of compute host

o   loss of connectivity with NTP Server

o   CPU Threshold exceeded on compute host

o   Memory Threshold exceeded on compute host

o   File System Threshold exceeded on compute host

o   etc.

· ... which would be type/granularity of ‘Alarm Type’ that i would 
think the user would want to suppress alarms based on.

· i.e. it seems like the ‘name’ field is a combination of this general 
Alarm Type and details on 

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

[Waines, Greg]

Thinking about this more ...
· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?
ocould be an optional field
obut we’d display in the alarm list
oand we’d use it as the mechanism to suppress alarms by ‘type’


Other option:

· wrt specifying which alarms to suppress,

ocould use combination of

§  ‘vitrage_type (enum)’ field - e.g. collectd, nagios, zabbix, vitrage, ...

§  and

§  a regexp on the ‘name (string)’ field

Thoughts ?
Greg.


From: Greg Waines <greg.wai...@windriver.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Friday, December 1, 2017 at 8:45 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by 
type and/or resource in Vitrage

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

o   vitrage_id (uuid) - unique identifier of an instance of an alarm

o   vitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

o   name (string) - the alarm description

o   vitrage_resource_type (enum) - e.g. nova.instance, nova.host, port, ...

o   vitrage_resource_id (uuid) - resource instance

o   vitrage_aggregated_severity

o   vitrage_operational_severity

o   update_timestamp

·

· there definitely is a specific resource identifier in order to be 
able to suppress alarms from a particular resource

·

· BUT there doesn’t seem like there is a general alarm type field
i.e. that would classify the type of problem that’s occurring
e.g.

o   communication failure with compute host

o   loss-of-signal on port of compute host

o   loss of connectivity with NTP Server

o   CPU Threshold exceeded on compute host

o   Memory Threshold exceeded on compute host

o   File System Threshold exceeded on compute host

o   etc.

· ... which would be type/granularity of ‘Alarm Type’ that i would 
think the user would want to suppress alarms based on.

· i.e. it seems like the ‘name’ field is a combination of this general 
Alarm Type and details on the particular alarm.

·

· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?

o   could be an optional field

o   but we’d display in the alarm list

o   and we’d use it as the mechanism to suppress alarms by ‘type’

 Let me know what you think ?


Greg.







__
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

[openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

[Waines, Greg]

Hey,

I am interested in getting some feedback on a proposed blueprint for Vitrage.

BLUEPRINT:

TITLE: Add the ability to ‘suppress’ alarms by Alarm Type and/or Resource

When managing a cloud, there are situations where a particular alarm or a set 
of alarms from a particular resource are occurring frequently, however they are 
identifying issues that are not of concern, at least for the time being.  For 
example, new hardware is in the process of being installed and resulting in 
alarms to occur, or remote servers (e.g. NTP Servers) are unreliable and result 
in frequent connectivity alarms.   In these situations, these irrelevant alarms 
are cluttering the alarm displays and it would be helpful to be able to 
suppress these alarms.

Suppressed alarms would not be shown in Active Alarm lists or Historical Alarm 
lists, and would not be included in alarm counts.
There would be a CLI Option / Horizon Button, to enable looking at Alarms that 
are currently suppressed.
( i.e. the idea would be that suppressed alarms would still be tracked, they 
just would not be displayed by default)

Thoughts on usefulness ?



Questions on how to implement this in Vitrage

· from an end user’s point of view, alarms have the following fields

ovitrage_id (uuid) - unique identifier of an instance of an alarm

ovitrage_type (enum) - e.g. collectd, nagios, zabbix, vitrage, ...
  - really an identifier of the general 
entity reporting the alarm

oname (string) - the alarm description

ovitrage_resource_type (enum) - e.g. nova.instance, nova.host, port, ...

ovitrage_resource_id (uuid) - resource instance

ovitrage_aggregated_severity

ovitrage_operational_severity

oupdate_timestamp

·

· there definitely is a specific resource identifier in order to be 
able to suppress alarms from a particular resource

·

· BUT there doesn’t seem like there is a general alarm type field
i.e. that would classify the type of problem that’s occurring
e.g.

ocommunication failure with compute host

oloss-of-signal on port of compute host

oloss of connectivity with NTP Server

oCPU Threshold exceeded on compute host

oMemory Threshold exceeded on compute host

oFile System Threshold exceeded on compute host

oetc.

· ... which would be type/granularity of ‘Alarm Type’ that i would 
think the user would want to suppress alarms based on.

· i.e. it seems like the ‘name’ field is a combination of this general 
Alarm Type and details on the particular alarm.

·

· Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ 
as a mechanism to identify the general type of problem or alarm being reported 
in order to address this ?

ocould be an optional field

obut we’d display in the alarm list

oand we’d use it as the mechanism to suppress alarms by ‘type’

 Let me know what you think ?


Greg.







__
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

[openstack-dev] [vitrage] required changes on existing devstacks

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Due to the latest changes of the event persistor service in Vitrage[1], there 
is a need to run vitrage-dbsync on any existing devstack:

· Pull the latest changes of vitrage (if you pulled yesterday you 
should pull again)

· Run: vitrage-dbsync

[1]  https://review.openstack.org/#/c/521359/

Thanks,
Ifat.

__
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

[openstack-dev] [vitrage] send notification when update vertex

[dong.wenjuan]

Hi dan,






I use Vitrage master branch to test 'host_down' scenario.. 


When scenario_evaluator match  the ''host_down_alarm_on_host" scenario and Do 
'mark_down' action,

Process update the vertex in entity graph and then should send the notification.

But currently, it didn't send the notification.

I trace the log but didn't find the reason.

Can you help me to have a look at? Thanks~







The vitrage-graph log and config file are in attachment.  From i post the 
'computer.host.down' event  to finish the evaluator.


Use the 'host_down' template in Vitrage repo: 
etc/vitrage/templates.sample/host_down_scenarios.yaml






BR,


dwj

vitrage.conf
Description: Binary data


vitrage_graph_for_host_down.txt
Description: Binary data
__
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

[openstack-dev] [vitrage] some error in Aodh datasource

[dong.wenjuan]

Hi Idan Kinory,






I deploy Vitrage with devstack using master branch.


Currently I found a error in Aodh datasource when I change the Aodh alarm 
state(alarm_state_transition notification).






The error log is as follows:


Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:30:50.429 
9880 DEBUG vitrage.datasources.listener_service [-] EVENT ENQUEUED:
Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: {'description': u'Alarm 
when * event occurred.', 'resource_id': None, 'vitrage_entity_type': 'aodh', 
'timestamp': u'2017-10-26T06:37:41.353447', 'state_timestamp': 
u'2017-10-27T07:09:06.636137', 'name': u'dwj', 'vitrage_datasource_action': 
'update', 'severity': u'low', 'vitrage_sample_date': '2017-10-27 
07:30:50.382730+00:00', 'vitrage_event_type': u'alarm.deletion', 'enabled': 
True, 'alarm_id': u'9578d0eb-5d09-49a2-80e9-fb1a6c7ce7e9', 'state': u'alarm', 
'repeat_actions': False, 'event_type': (u'*',), 'project_id': 
u'378f268c64fc42c28226704dd71f37fe', 'type': u'event'} _enqueue_events 
/opt/stack/vitrage/vitrage/datasources/listener_service.py:106
Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.327 
10104 DEBUG vitrage.datasources.services [-] start get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:119
Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.331 
10104 DEBUG vitrage.datasources.services [-] end get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:126
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver [-] Failed to Convert alarm state 
transition event - 'dict' object has no attribute 'encode': AttributeError: 
'dict' object has no attribute 'encode'
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver Traceback (most recent call last):
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver   File 
"/opt/stack/vitrage/vitrage/datasources/aodh/driver.py", line 352, in 
_convert_alarm_state_transition_event
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver unicode_to_str = 
state.encode("ascii")
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver AttributeError: 'dict' object has no 
attribute 'encode'



I noticed that you fix the code in this patch(Line 352-368): 
https://review.openstack.org/#/c/501701/4/vitrage/datasources/aodh/driver.py


Can you please explain why? Thanks.




BR,

dwj__
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

[openstack-dev] [vitrage] Reminder: Vitrage virtual PTG this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

We will hold the Vitrage Queens virtual PTG this week, on October 17-19. You 
are welcome to join!
More details can be found in the etherpad[1].
The regular weekly IRC meeting will be canceled.

[1] https://etherpad.openstack.org/p/vitrage-ptg-queens

Thanks,
Ifat.

__
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

Re: [openstack-dev] [vitrage] Question about vitrage workings.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

Vitrage is supposed to be automatically updated when a VM is deleted from Nova. 
There are a few issues I would check in your case.


1.   You said that you were using vitrage 1.3.1. The Newton version of 
vitrage is 1.3.0, there is no 1.3.1 version. Maybe you meant vitrage-dashboard 
1.3.1 (which is the Pike version)? Can you please send me the exact versions of 
vitrage, vitrage-dashboard and python-vitrageclient?

2.   Please verify that Nova is configured to send notifications to 
Vitrage. In /etc/nova/nova.conf you should have:

notification_topics = notifications,vitrage_notifications

3.   Is Vitrage automatically updated when a new VM is created?

4.   In addition to receiving notifications, Vitrage queries all of its 
datasources once in 10 minutes for an updated list of resources. If you wait 10 
minutes, is the VM removed from Vitrage?

5.   Do you know the exact time that the VM is removed from Nova? If so, 
can you please send me the vitrage-graph.log from this time?

Thanks,
Ifat.

From: Paul Vaduva <paul.vad...@enea.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 11 October 2017 at 14:15
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Question about vitrage workings.

Hi Vitrage team,

I have a question about vitrage workings. We use vitrage 1.3.1 with openstack 
newton release.
We have a NFV use case scenario where we get faults to compute nodes or 
openstack services (e.g. nova) that makes virtual machines running on that host 
to get lost / removed. We use a combination of alarms and Tacker to respawn a 
VM but sometimes (e. g. nova-compute service is faulted) we lose contact with 
the old vm and cannot delete it. When this happens somehow openstack is aware 
that vm is not in existence anymore (by means of “openstack server list” I 
mean) but Vitrage is still showing that vm as running.
My question is if there is a way to resynchronize VM state in Vitrage with the 
state from openstack.

Best Regards,
Paul Vaduva

__
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

[openstack-dev] [vitrage] Question about vitrage workings.

[Paul Vaduva]

Hi Vitrage team,

I have a question about vitrage workings. We use vitrage 1.3.1 with openstack 
newton release.
We have a NFV use case scenario where we get faults to compute nodes or 
openstack services (e.g. nova) that makes virtual machines running on that host 
to get lost / removed. We use a combination of alarms and Tacker to respawn a 
VM but sometimes (e. g. nova-compute service is faulted) we lose contact with 
the old vm and cannot delete it. When this happens somehow openstack is aware 
that vm is not in existence anymore (by means of "openstack server list" I 
mean) but Vitrage is still showing that vm as running.
My question is if there is a way to resynchronize VM state in Vitrage with the 
state from openstack.

Best Regards,
Paul Vaduva

__
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

[openstack-dev] [vitrage] No IRC meeting this week

[Paul Vaduva]

Hi Vitrage team,

I have a question about vitrage workings. We use vitrage 1.3.1 with openstack 
newton release.
We have a NFV use case scenario where we get faults to compute nodes or 
openstack services (e.g. nova) that makes virtual machines running on that host 
to get lost / removed. We use a combination of alarms and Tacker to respawn a 
VM but sometimes (e. g. nova-compute service is faulted) we lose contact with 
the old vm and cannot delete it. When this happens somehow openstack is aware 
that vm is not in existence anymore (by means of "openstack server list" I 
mean) but Vitrage is still showing that vm as running.
My question is if there is a way to resynchronize VM state in Vitrage with the 
state from openstack.

Best Regards,
Paul Vaduva
__
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

[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting this week is canceled, as many Vitrage contributors will be on 
vacation.
Next week we will hold the Vitrage virtual PTG on Tue-Thu, October 17-19. More 
details can be found in the etherpad:
https://etherpad.openstack.org/p/vitrage-ptg-queens

Best Regards,
Ifat.

__
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

[openstack-dev] [vitrage] Vitrage virtual PTG

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

We will hold the Vitrage virtual PTG on October 17-19. I have created an 
initial schedule draft, you are more than welcome to comment or suggest new 
topics for discussion:
https://etherpad.openstack.org/p/vitrage-ptg-queens

Best Regards,
Ifat.

__
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

Re: [openstack-dev] [vitrage] Extending Topology

[Muhammad Usman]

Thanks Ifat,

For guiding me to how to start with contribution on implementation side.

Meanwhile, I am looking at blueprints and bugs before attending next
meeting.

-- 

*Regards*

*Muhammad Usman*
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068

On Fri, Sep 22, 2017 at 5:22 AM, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi Usman,
>
>
>
> Great to hear back from you J
>
>
>
> You are more than welcome to join our efforts. You can look at the list of
> blueprints[1], suggest new ones, implement existing, or solve bugs[2].
> Whatever you chose, we will be happy to assist.
>
>
>
> The ways to contact Vitrage developers are here in the mailing list, or on
> #openstack-vitrage IRC channel. In addition, we meet every Wednesday at
> 8:00 UTC on #openstack-meeting-4, so you can join and discuss whatever
> topic you are interested in.
>
>
>
> [1] https://blueprints.launchpad.net/vitrage
>
> [2] https://bugs.launchpad.net/vitrage
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
> *From: *Muhammad Usman <usman...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, 21 September 2017 at 4:59
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] Extending Topology
>
>
>
> Dear Ifat,
>
>
>
> Usman is here. Previously, I contacted you for contributing to OpenStack
> Vitrage project but could not  follow up with you for sometime due to
> various reasons.
>
>
>
> However, to get actively involved in OpenStack project, I have decided to
> join OpenStack Summit in Sydney.
>
>
>
> Also, based on my previous experience withe Vitrage project that is
> already in shape, so its not easy to propose new ideas.
>
>
>
> Therefore, a better way to start contributing to development side with
> already proposed and on-going development.
>
>
> --
>
>
> * Regards*
>
>
> *Muhammad Usman*
> Application Engineer
> LMK Resources (pvt) Limited
> www.lmkr.com
> +92 (323) 5599 068
>
>
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [vitrage] Extending Topology

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Usman,

Great to hear back from you ☺

You are more than welcome to join our efforts. You can look at the list of 
blueprints[1], suggest new ones, implement existing, or solve bugs[2]. Whatever 
you chose, we will be happy to assist.

The ways to contact Vitrage developers are here in the mailing list, or on 
#openstack-vitrage IRC channel. In addition, we meet every Wednesday at 8:00 
UTC on #openstack-meeting-4, so you can join and discuss whatever topic you are 
interested in.

[1] https://blueprints.launchpad.net/vitrage
[2] https://bugs.launchpad.net/vitrage

Best Regards,
Ifat.

From: Muhammad Usman <usman...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 21 September 2017 at 4:59
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Extending Topology

Dear Ifat,

Usman is here. Previously, I contacted you for contributing to OpenStack 
Vitrage project but could not  follow up with you for sometime due to various 
reasons.

However, to get actively involved in OpenStack project, I have decided to join 
OpenStack Summit in Sydney.

Also, based on my previous experience withe Vitrage project that is already in 
shape, so its not easy to propose new ideas.

Therefore, a better way to start contributing to development side with already 
proposed and on-going development.

--

Regards

Muhammad Usman
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com<http://www.lmkr.com/>
+92 (323) 5599 068


__
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

Re: [openstack-dev] [vitrage] Extending Topology

[Muhammad Usman]

Dear Ifat,

Usman is here. Previously, I contacted you for contributing to OpenStack
Vitrage project but could not  follow up with you for sometime due to
various reasons.

However, to get actively involved in OpenStack project, I have decided to
join OpenStack Summit in Sydney.

Also, based on my previous experience withe Vitrage project that is already
in shape, so its not easy to propose new ideas.

Therefore, a better way to start contributing to development side with
already proposed and on-going development.

-- 

*Regards*

*Muhammad Usman*
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068

On Mon, Mar 27, 2017 at 7:32 PM, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
> Let me try and explain the more general use case.
>
> You can query OVS for the switches information, and understand how they
> are mapped to one another. This is not enough for knowing the exact route
> of the network traffic for a certain VM.
>
> A certain switch can be connected to more than one other switch. You can,
> as you said, query the network type (encapsulation) information from
> Neutron. But then you will need in addition to query the rules of the
> specific switch from OVS, in order to know which route to take for each
> encapsulation type.
>
> Another problematic use case is when the switches are not connected to
> each other. The traffic can be redirected by a network-stack software
> component, so you will have to query it in addition in order to tell the
> route.
>
> And on top of all this, we need to think how to best represent this
> information in Vitrage (i.e. how to draw the graph, which vertices to
> connect to one another, etc.).
>
> IMO, this is all feasible and will give a lot of value to Vitrage. Just
> not easy to implement.
>
> Best Regards,
> Ifat.
>
>
> On 22/03/2017, 08:50, "Muhammad Usman"  wrote:
>
> Hello Ifat,
>
> I tried to see more in depth about the issues you mentioned regarding
> the extension of vSwitches. Due to a lot of complexity involved in
> generating this topology and associated effects, I believe we need to
> setup some baseline (e.g. adding a configuration file for specifying
> bridges in existing deployment setup). Then using that baseline,
> topology can be constructed as well as type of network can be
> extracted from neutron and associated path followed (e.g. vlan or
> vxlan). However, more general case you mentioned, I cannot get it. Do
> you mean nova-network?
>
> Regarding the sunburst representation -  Yes I agree, if you want to
> keep compute hierarchy separate then addition of networking components
> is not a good idea.
>
> Also, suggestions from other vitrage members are welcomed.
>
>
> > On Thu, Mar 16, 2017 at 6:44 PM, Afek, Ifat (Nokia - IL) <
> > ifat.a...@nokia.com > wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> Adding switches to the Vitrage topology is generally a good idea,
> but the
> >> implementation might be very complex. Your diagram shows a simple
> use
> > case,
> >> where all switches are linked to one another and it is easy to
> determine
> >> the effect of a failure on the vms. However, in the more general
> case
> > there
> >> might be switches without a connecting port (e.g. they might be
> connected
> >> via the network stack). In such cases, it is not clear how to model
> the
> >> switches topology in Vitrage. Another case to consider is when the
> >> network
> >> type affects the packets path, like vlan vs. vxlan. If you have an
> idea
> >> of
> >> how to solve these issues, I will be happy to hear it.
> >>
> >>
> >>
> >> Regarding the sunburst representation – I’m not sure I understand
> your
> >> diagram. Currently the sunburst is meant to show (only) the compute
> >> hierarchy: zones, hosts and instances. It is arranged in a
> containment
> >> relationship, i.e. every instance on the outer ring appears next to
> its
> >> host in the inner ring. If you add the bridges in the middle, you
> lose
> > this
> >> containment relationship. Can you please explain to me the suggested
> >> diagram?
> >>
> >>
> >>
> >> BTW, you can send such questions to OpenStack mailing list (
> >> openstack-dev@lists.openstack.org ) with [vitrage]
> tag in
> > the title, and
> >> possibly get replies from other contributors as well.
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Ifat.
> >>
> >>
> >>
> >>
> >>
> >> *From: *Muhammad Usman >
> >> *Date: *Monday, 13 March 2017 at 09:16
> >>
> >> *To: *"Afek, Ifat (Nokia - IL)"  >
> >> *Cc: *JungSu Han >
> >> *Subject: *Re: OpenStack Vitrage
> >>
> >>
>  

[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting on the coming Wednesday (September 20th) is canceled, as many 
Vitrage contributors will be on vacation. We will meet again next week, on 
September 27th.

Best Regards,
Ifat.

__
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

[openstack-dev] [vitrage] Vitrage Queens virtual PTG

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi All,

As agreed in Doodle[1] and in today’s IRC meeting[2], We will hold the Vitrage 
Virtual PTG on the following dates (all times are UTC):

Tue, October 17: 6:30-9:30, 10:30-12:00 
Wed, October 18:  6:30-9:30 
Thu, October 19 (Optional): 6:30-9:30, 10:30-12:00 

Feel free to add your name and topics to the PTG etherpad[3].

[1] https://beta.doodle.com/poll/nh9czcvfayystf9u 
[2] 
http://eavesdrop.openstack.org/meetings/vitrage/2017/vitrage.2017-09-06-08.02.html
 
[3] https://etherpad.openstack.org/p/vitrage-ptg-queens 

Best Regards,
Ifat.


__
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

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Greg,

Can you please send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 6 September 2017 at 3:07
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "OpenStack 
Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "TAHHAN, MARYAM" <maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

That worked :)
Thanks a lot Ifat.

I see the cpu alarm reported in vitrage now :).
( and in the /tmp/python-notifications.dump file that volodomyr helped me with )

Only final issue is that the vitrage alarm does not clear when I see the clear 
notification ( ? severity 4 ? )in /tmp/python-notifications.dump.
I waited about 10 mins ... in case there was some hysteresis or something.

I am using a late version of ocata.

in /tmp/python-notifications.dump:
host: devstack-vitrage
plugin: cpu
plugin_instance: 0
type: percent
type_instance: idle
time: 1504655183.27
severity: 1
message: Host devstack-vitrage, plugin cpu (instance 0) type percent (instance 
idle): Data source "value" is currently 0.00. That is below the failure 
threshold of 20.00.



host: devstack-vitrage
plugin: cpu
plugin_instance: 0
type: percent
type_instance: idle
time: 1504655228.27
severity: 4
message: Host devstack-vitrage, plugin cpu (instance 0) type percent (instance 
idle): All data sources are within range again. Current value of "value" is 
96.306246.

// 20 minutes later ,,, still see
stack@devstack-vitrage:~/devstack$ vitrage alarm list --max-width 80
++--+--+---+-+-+--+--+
| vitrage_id | vitrage_type | name | vitrage_resource_type | 
vitrage_resource_id | vitrage_aggregated_severity | 
vitrage_operational_severity | update_timestamp |
++--+--+---+-+-+--+--+
| af0cd49f-8 | collectd | Host dev | nova.host | 
a7bca8d3-c84f-46cd- | FAILURE | CRITICAL
 | 2017-09-05T23:46 |
| d02-4173-8 |  | stack-   |   | 
a8db-cccab2851660   | | 
 | :23Z |
| b56-37e19e |  | vitrage, |   |
 | |  | 
 |
| cf7dfb |  | plugin   |   |
 | |  | 
 |
||  | cpu (ins |   |
 | |  | 
 |
||  | tance 0) |   |
 | |  | 
 |
||  | type |   |
 | |  | 
 |
||  | percent  |   |
 | |  | 
 |
||  | (instanc |   |
 | |  | 
 |
||  | e idle): |   |
 | |  | 
 |
||  | Data |   |
 | |  | 
 |
||  | source   |   |
 | |  | 
 |
||  | "value"  |   |
 | |  | 
 |
||  | is curre |   |
 | |  | 
 |
||  | ntly 0.0 |   |
 |   

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

[Waines, Greg]

  |  | failure  |   |
 | |  | 
 |
||  | threshol |   |
 | |  | 
 |
||  | d of 20. |   |
 | |  | 
 |
||  | 00.  |   |
 | |  | 
 |
++--+--+---+-+-+--+--+
stack@devstack-vitrage:~/devstack$


Greg.



From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Date: Tuesday, September 5, 2017 at 9:43 AM
To: Greg Waines <greg.wai...@windriver.com>, 
"openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Cc: "TAHHAN, MARYAM" <maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

There is an exception in vitrage-graph, since the configuration for 
devstack-vitrage/cpu/0 was not found.

Please verify that your collectd_conf.yaml looks like that:

collectd:
- collectd_host: devstack-vitrage/cpu/0
   type: 
   name: 
- collectd_host: …

If this doesn’t help, please send me the file and I’ll have a look.

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Tuesday, 5 September 2017 at 15:38
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "OpenStack 
Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "TAHHAN, MARYAM" <maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,

I was able to fix and verify that my collectd configuration is correct and 
working with the help of volodomyr ... i.e. I have a much simpler collectd.conf 
with a threshold set on cpu-0 idle percentage and a simple python plugin to 
dump notifications to a file.

I added in the vitrage collectd plugin to this simple setup ... but still don’t 
see vitrage alarms displayed on the vitrage dashboard ☹ .

I have attached the vitrage-graph.log
I have attached my now much simpler collectd.conf file
I have also attached the only templates I have defined under 
/etc/vitrage/templates  ... wondering if I need updated templates for working 
with collectd notifications ?

let me know if you have any ideas,
Greg.



From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Date: Sunday, September 3, 2017 at 3:20 AM
To: Greg Waines <greg.wai...@windriver.com>, 
"openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Cc: "TAHHAN, MARYAM" <maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

You should access the vitrage-graph.log using journalctl:
sudo journalctl --no-pager --unit 
devstack@vitrage-graph.service<mailto:devstack@vitrage-graph.service>

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Thursday, 31 August 2017 at 20:10
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "OpenStack 
Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "TAHHAN, MARYAM" <maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
I actually have ‘debug = true’ in /etc/vitrage/vitrage.conf .
However I don’t see vitrage-graph.log anywhere ?
Where is it suppose to be ?   in /var/log/ ?
Greg.


root@devstack-vitrage:/# more /etc/vitrage/vitrage.conf



[DEFAULT]

debug = True

transport_url = rabbit://stackrabbit:admin@10.10.10.13:5672/



[oslo_policy]

policy_file = /etc/vitrage/policy.json



[service_credentials]

auth_url = http://10.10.10.13/identity

region_name = RegionOne

project_name = admin

password = admin

project_domain_id = default

user_domain_id = default

username = vitrage

auth_type = password



[datasources]

types = 
nova.host,nova.instance,nova.zone,static,static_physical,aodh,cinder.volume,neutron.network,neutron.port,doctor,collectd



[keystone_authtoken]

memcached_servers = 10.10.10.13:11211

signing_dir = /var/cache/vitrage

cafile = /opt/stack/data/ca-bundle.pem

project_domain_name = Default

project_name = admin

user_domain_name = Default

password = admin

username = vitrage

auth_url = http://10.10.10.13/identity

auth_type = password



[api]

pecan_debug = False



[collectd]

config_file = /etc/vitrage/collectd_conf.yaml



root@devstack-vitrage:/#


From: "Afek, Ifat (Nokia - IL/Kf