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://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://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] 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

[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

[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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'" 

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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

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

From: Renat Akhmerov 
Date: Monday, 23 April 2018 at 9:45

On 23 Apr 2018, 13:38 +0700, Jaewook Oh , wrote:


Hello Mistral and Vitrage team,

I've been testing vitrage with mistral workflow,
but it seems that there are no Vitrage actions in Mistral yet.

I think Vitrage actions should be added to Mistral.
We can use the actions in mistral workflow to automate lots of repeated tasks 
as it was originally intended.

So, I'd like to add them to the Mistral Actions.
Can I do this work?

Hi, I see no reason why not. We’ll assist, if needed. I’d recommend to join us 
at #openstack-mistral IRC channel for better communication.

Thanks

Renat Akhmerov
@Nokia


Hi,

Sounds like a good idea, let us know if you need any help from Vitrage 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] 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.

[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.

[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

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.

[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 

[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.

[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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 27 March 2018 at 14:45
To: "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

[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

[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] [heat][horizon][ironic][neutron][swift][tricircle][vitrage][watcher] Help needed for your release

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

Hi,

I will request to a create stable/queens branch for Vitrage later today.

Thanks,
Ifat.

On 07/02/2018, 18:49, "Matthew Thode"  wrote:

On 18-02-07 16:33:52, Luke Hinds wrote:
> On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode 
> wrote:
> 
> > Hi all,
> >
> > it looks like some of your projects may need to cut a queens
> > branch/release.  Is there anything we can do to move it along?
> >
> > The following is the list I'm working off of (will be updated as
> > projects release)
> > https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
> >
> > As of right now it's as follows.
> 
> 
> From what I know anchor (security) has no maintainers / cores now, so I
> guess it would make sense to perhaps archive (I will follow this through
> outside this thread), so for now there is no need to tag a queens branch /
> release.

Ya, a bunch of those are maintainerless, the ones of primary concern are
those managed by ironic, swift, tricircle, vitrage, watcher, heat and 
neutron

-- 
Matthew Thode (prometheanfire)


__
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

[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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 7 February 2018 at 11:58
To: "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][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)" <ifat.a...@nokia.com> 
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] [requirements] [vitrage][glance] global requirements update for python-vitrageclient

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

Adding Glance team. 
Any idea what could be wrong?

Thanks,
Ifat.


On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com> 
wrote:

Hi,

I tried to update the version of python-vitrageclient [1], but the 
legacy-requirements-integration-dsvm test failed with an error that does not 
seem related to my changes:

error: can't copy 'etc/glance-image-import.conf': doesn't exist or not a 
regular file

I noticed that two other changes [2][3] failed with the same error.

Can you please help?

Thanks,
Ifat.


[1] https://review.openstack.org/#/c/537307
[2] https://review.openstack.org/#/c/535460/
[3] https://review.openstack.org/#/c/536142/



__
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] [requirements] [vitrage] global requirements update for python-vitrageclient

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

Hi,

I tried to update the version of python-vitrageclient [1], but the 
legacy-requirements-integration-dsvm test failed with an error that does not 
seem related to my changes:

error: can't copy 'etc/glance-image-import.conf': doesn't exist or not a 
regular file

I noticed that two other changes [2][3] failed with the same error.

Can you please help?

Thanks,
Ifat.


[1] https://review.openstack.org/#/c/537307   
[2] https://review.openstack.org/#/c/535460/ 
[3] https://review.openstack.org/#/c/536142/ 


__
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] [congress] generic push driver

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

From: Eric K <ekcs.openst...@gmail.com>
Date: Tuesday, 9 January 2018 at 0:43

Hi Ifat,

From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>>
Date: Sunday, January 7, 2018 at 4:00 AM


Hi Eric,

I have two questions:


1.  An alarm is usually raised on a resource, and in Vitrage we can send 
you the details of that resource. Is there a way in Congress for the alarm to 
reference a resource that exists in another table? And what if the resource 
does not exist in Congress?
First, the columns I chose are just a minimal sample to illustrate the generic 
nature of the driver. In use with vitrage, we would probably also want to 
include columns such as `resource_id`. Does that address the need to reference 
a resource? That resource referenced by ID may or may not exist in another part 
of Congress. It would be the job of the policy to resolve references when 
taking appropriate actions. If referential integrity is needed, additional 
policy rules can be specified to catch breakage.

[Ifat] Ok, sounds good.

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

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

Exapmle:
- is the `resource` property an ID string or a python object reference?

[Ifat] Most of the properties are key-value strings on the vertex in the entity 
graph. The RESOURCE is a special property that is added on an alarm for the use 
of the notifier. It holds the entire resource object, so the notifier could use 
its properties when sending notifications.

- what does the property `is_real_vitrage_id`
represent?

[Ifat] It represents old code that should be deleted ;-) please ignore it

- what is the difference between `resource_id` and `vitrage_resource_id` ?

[Ifat] resource_id is the id of the resource as retrieved by the datasource, 
e.g. the Nova instance id
 vitrage_id is the id of the resource inside Vitrage. This is the id 
that Vitrage uses to identify its resources. For a Nova instance, vitrage_id 
will be different from its resource_id.
 vitrage_resource_id is used only on alarms, and holds the vitrage_id 
of the resource of the alarm.



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

[Ifat] It’s really up to you, I think both would satisfy the use case. The 
Congress notifier will be written based on your selected implementation.


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

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)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 9 January 2018 at 8:34
To: "OpenStack Development Mailing List (not for usage questions)" 

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) 
> 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] [congress] generic push driver

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

Hi Eric,

I have two questions:


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

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

Thanks,
Ifat


From: Eric K 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, 6 January 2018 at 3:50
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [congress] generic push driver

We've been discussing generic push drivers for Congress for quite a while. 
Finally sketching out something concrete and looking for some preliminary 
feedback. Below are sample interactions with a proposed generic push driver. A 
generic push driver could be used to receive push updates from vitrage, 
monasca, and many other sources.

1. creating a datasource:

congress datasource create generic_push_driver vitrage --config schema='
{
  "tables":[
{
  "name":"alarms",
  "columns":[
"id",
"name",
"state",
"severity",
  ]
}
  ]
}
'

2. Update an entire table:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "rows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}
Note that a row can be either a {} or []


3. perform differential update:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "addrows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

OR

{
  "deleterows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together 
with some well defined semantics. Alternatively we may mandate that each 
request can have only one of the three pieces.

Note 2: we leave it as the responsibility of the sender to send and confirm the 
requests for differential updates in correct order. We could add sequencing in 
future work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[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

[openstack-dev] [requirements][vitrage] Networkx version 2.0

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

Hi,

There is an open bug in launchpad about the new release of Networkx 2.0, that 
is backward incompatible with versions 1.x [1].
Is there a plan to change the Networkx version in the global requirements in 
Queens? We need to make some code refactoring in Vitrage, and I’m trying to 
understand how urgent it is.

[1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576

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] [OpenStack][Vitrage] Vitrage Entity Graph supports various actions according to mouse events for entities.

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

Hi Minwook,

Do you mean that you would like to:

· Right click an entity

· Ask to run performance tests

· Wait for the results to show?

I assume that the performance test would take some time. Or do you expect to 
trigger the test execution and see the results later on, on the resource 
properties panel?

Regarding excluding the performance tests: I suggest to make the list of 
actions configurable, so every user can choose the wanted actions. It can also 
be configured per resource type, I guess.

Regarding ‘set monitoring configure’ – I’m not sure that it should be an 
action. We could, alternatively, add a ‘configuration’ menu for all kinds of 
configurations, regardless of the entity graph.

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, 14 December 2017 at 17:46
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack][Vitrage] Vitrage Entity Graph supports 
various actions according to mouse events for entities.

Hello Ifat.

Thanks for your comments.

The Performance Test action is completely independent of the Vitrage flow and 
is simply an action that triggers an external Performance Test project.

Users can simply see the results on the Vitrage-Dashboard.

We can also exclude Performance Test from the action list if they are not 
needed.

'set monitoring configure' is an example of an action that can be added. We can 
discuss the addition of required actions in the vitrage-dashboard at the 
development level.

In addition, my experience is to manually register entities in the 
/etc/vitrage/zabbix_conf.yaml file to use the monitoring configuration using 
zabbix and vitrage. Then restart the Entity-Graph service.

I think we can let this process automatically modify the zabbix_conf.yaml file 
by right-clicking on the desired entity in the Vitrage-Dashboard. (I think we 
can modify zabbix_conf.yaml automatically via SSH if we perform that action. we 
can enter the required parameters for this. )

As such, we can discuss the list to be included in the right mouse button 
action.

what do you think?

Best Regards,
Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, December 14, 2017 11:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack][Vitrage] Vitrage Entity Graph supports 
various actions according to mouse events for entities.

Hi MinWookKim,

I think that the right click is a good idea.

Some questions:


· Just to make sure I understood correctly – after the “performance and 
load test”, do you expect to see the result on the selected resource, or 
somewhere else?

· What do you mean by “set monitoring configure”?

Best Regards,
Ifat.


From: 김민욱 <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, 14 December 2017 at 8:29
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] [OpenStack][Vitrage] Vitrage Entity Graph supports 
various actions according to mouse events for entities.

Hello.

I'm MinWookKim.

I have been discussing my proposal with the Vitrage PTL a while ago,

I want to get feedback from Vitrage contributors.

In conclusion, my suggestion is that when I right-click on the Entity Graph 
provided by Vitrage, I want the user to perform various actions through the UI.

These actions include many things, and they do not go through the Vitrage 
interior.

Ask other projects directly.

This is similar to what appears when you right-click on an icon in Windows.

You can set various parameters for a specific action and pass it directly to 
the project.

The actions I thought so far are:
1. Execution of Mistral workflow
2. Performance & Load Test using external project for Entity
3. Set monitorig configure?

# Workflow

Entity click & select action
  |
Vitrage-Dashboard -> Mistral API -> Execute Workflow
   |
   --> Test Project API > Execute Test

I want to check the results of these actions on the UI.

For example, if the Performance & Load Test action is triggered on an Entity, 
the UI will display the following result.

Availability: 99.75%
Elapsed time: 59.66 secs
Data transferred: 10340918 bytes
Response time: 2.36 secs

The focus of this proposal 

[openstack-dev] [oslo][requirements][vitrage] oslo.service 1.28.1 breaks Vitrage gate

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

Hi,



The latest release of oslo.service 1.28.1 breaks the Vitrage gate. We are 
creating several threads and timers [1], but only the first thread is executed. 
We noticed that Trove project already reported this problem [2].



Please help us fix it.



Thanks,

Ifat.



[1] 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/services.py

[2] https://review.openstack.org/#/c/527755/




__
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] [OpenStack][Vitrage] Vitrage Entity Graph supports various actions according to mouse events for entities.

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

Hi MinWookKim,

I think that the right click is a good idea.

Some questions:


· Just to make sure I understood correctly – after the “performance and 
load test”, do you expect to see the result on the selected resource, or 
somewhere else?

· What do you mean by “set monitoring configure”?

Best Regards,
Ifat.


From: 김민욱 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 14 December 2017 at 8:29
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [OpenStack][Vitrage] Vitrage Entity Graph supports 
various actions according to mouse events for entities.

Hello.

I'm MinWookKim.

I have been discussing my proposal with the Vitrage PTL a while ago,

I want to get feedback from Vitrage contributors.

In conclusion, my suggestion is that when I right-click on the Entity Graph 
provided by Vitrage, I want the user to perform various actions through the UI.

These actions include many things, and they do not go through the Vitrage 
interior.

Ask other projects directly.

This is similar to what appears when you right-click on an icon in Windows.

You can set various parameters for a specific action and pass it directly to 
the project.

The actions I thought so far are:
1. Execution of Mistral workflow
2. Performance & Load Test using external project for Entity
3. Set monitorig configure?

# Workflow

Entity click & select action
  |
Vitrage-Dashboard -> Mistral API -> Execute Workflow
   |
   --> Test Project API > Execute Test

I want to check the results of these actions on the UI.

For example, if the Performance & Load Test action is triggered on an Entity, 
the UI will display the following result.

Availability: 99.75%
Elapsed time: 59.66 secs
Data transferred: 10340918 bytes
Response time: 2.36 secs

The focus of this proposal is to provide a click action for the Entity to 
provide convenience to the user.

What do you think?

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

[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" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 4 December 2017 at 15:34
To: "OpenStack Development Mailing List (not for usage questions)" 

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 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, December 1, 2017 at 8:45 AM
To: "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 

[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] 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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 11 October 2017 at 14:15
To: "OpenStack Development Mailing List (not for usage questions)" 

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] FW: [vitrage]Vitrage Devstack on master

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

From: "Hefetz, Idan (Nokia - IL/Kfar Sava)" 


Hi,
To use Vitrage Devstack on master, please notice that after this 
commit, a few steps are required:


  1.  Add the following to  /etc/vitrage/vitrage.conf
[database]
connection = mysql+pymysql://root:password@127.0.0.1/vitrage?charset=utf8


  1.  Add the following to /opt/stack/vitrage/vitrage.egg-info/entry_points.txt
[vitrage.storage]
mysql = vitrage.storage.impl_sqlalchemy:Connection
mysql+pymysql = vitrage.storage.impl_sqlalchemy:Connection
postgresql = vitrage.storage.impl_sqlalchemy:Connection
sqlite = vitrage.storage.impl_sqlalchemy:Connection


  1.  Run ‘sudo service apache2 restart’
  2.  Run ‘sudo service devstack@vitrage-graph restart’

Another option is to recreate the stack using stack.sh.

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

[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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 21 September 2017 at 4:59
To: "OpenStack Development Mailing List (not for usage questions)" 

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

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

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/Kfar Sava)" <ifat.a...@nokia.com>
Date: Thursday, August 31, 2017 at 3:52 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,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "TAHHAN, MARYAM" 
<maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-

Re: [openstack-dev] [all] connecting nova notification users and developers

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

Hi,

Vitrage holds a topology graph with all resources in the system and the 
relationships between them, for fault correlation purposes[1]. It uses 
notifications from Nova (as well as from other components) to update its 
internal state[2]. 

It is important for us to get immediate notifications about state changes, so 
we can react fast. For example, if a new instance is created on a host with 
high CPU load, we will immediately raise an alarm on that instance that it may 
suffer from CPU performance degradation.

I’ll be happy to discuss our use cases at the PTG.

[1] https://wiki.openstack.org/wiki/Vitrage  
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/nova/instance/driver.py

Best Regards,
Ifat.


On 30/08/2017, 17:30, "Balazs Gibizer"  wrote:

Hi,

Nova emits notifications for many different event, like different 
instance actions[1]. Also the nova developer community is working on 
making nova notifications well defined and easy to consume [2].

The goal of this mail is twofold.

1) We in the nova developer community would like to see which projects 
are using (or planning to use) the nova notification interface. Also we 
would like to know if you are using the legacy unversioned 
notifications or the new versioned ones. We would like to know what are 
your use cases towards our notification interface and we also would 
like to get any type of feedback about the interface (both the old and 
the new one). Based on this information we can make better decision 
where to focus our development effort. As a good example we already 
have a  cooperation with the searchlight project to enhance nova's 
versioned notification interface based on their needs [3].

I opened an etherpad [4] to collect the projects and the feedback and 
we can go through that feedback in the PTG to define some actions.

2) Creating a well defined and easy to use notification interface gives 
us plenty of work in nova. So we are also looking for developers who 
can help us in this work. Big chunk of [2] is considered as low hanging 
fruit and I'm happy to mentor anybody who is interested learning this 
part of nova. If you want to join to this work just ping me (gibi) or 
IRC.

Cheers,
gibi

[1]https://docs.openstack.org/nova/latest/reference/notifications.html

[2]https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-queens

[3]https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
[4]https://etherpad.openstack.org/p/queens-nova-notifications


__
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] Collectd - to - Vitrage setup issues

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

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/Kfar Sava)" <ifat.a...@nokia.com>
Date: Thursday, August 31, 2017 at 3:52 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,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "TAHHAN, MARYAM" 
<maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 
THRESHOLD Events to vitrage.
i.e. it likely does NOT send just statistic/status samples to vitrage.

I can see that collectd sampling is happening ... I have logfile and csv and 
rrd plugins running and samples are being captured in the specified directories 
/ files.

I tried to set threshold for CPU based on an example I had found on web.
See attached collectd.conf file .

BUT really not sure if the threshold configuration in my collectd.conf is 
correct or working ... is there a way to confirm this ?   ( any collectd 
experts out there ? )
OR
Is there an example collectd.conf that has notifications or thresholds 
(whatever vitrage needs) setup for something basic like CPU ?

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, August 28, 2017 at 9:42 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

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

Hi Greg,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>, "TAHHAN, MARYAM" 
<maryam.tah...@intel.com>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 
THRESHOLD Events to vitrage.
i.e. it likely does NOT send just statistic/status samples to vitrage.

I can see that collectd sampling is happening ... I have logfile and csv and 
rrd plugins running and samples are being captured in the specified directories 
/ files.

I tried to set threshold for CPU based on an example I had found on web.
See attached collectd.conf file .

BUT really not sure if the threshold configuration in my collectd.conf is 
correct or working ... is there a way to confirm this ?   ( any collectd 
experts out there ? )
OR
Is there an example collectd.conf that has notifications or thresholds 
(whatever vitrage needs) setup for something basic like CPU ?

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, August 28, 2017 at 9:42 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

[collectd]
config_file = /etc/vitrage/collectd_conf.yaml

Then you should restart vitrage-graph.

Let me know if it helped,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 23 August 2017 at 21:19

I am trying to get collectd to report some alarms to vitrage in a devstack 
setup,

I am using a devstack created on a late version of ocata.
And my devstack with vitrage appears to be working ok otherwise;
e.g.  I can create VMs, and raise fake alarms using “vitrage event post 
-type=compute.host.down ...” or with “aodh alarm create ... 
resource_id=instance-uuid” ... and they get reported fine in vitrage.

UNFORTUNATELY not seeing anything in vitrage from collectd, and
  don’t believe I’m seeing anything even from collectd, 
for example from the syslog output plugin.

I’ve attached the following files:   ( not sure if these get distributed on 
mailing list )
· /etc/collectd/collectd.conf   <-- do these look ok ?
· /etc/vitrage/vitrage.conf  <-- do these look ok ?
· /var/log/syslog ... around the time when I updated 
collectd.conf and vitrage.conf and restarted collectd and vitrage-graph
oQUESTIONS
•  NOTE THE FOLLOWING ERRORS IN THE SYSLOG FILE ... where do I get the 
collectd_conf.yaml file from ?  Can’t see it in the devstack files for vitrage.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.039 25962 ERROR vitrage.utils.file [-] File doesn't exist: 
/etc/vitrage/collectd_conf.yaml.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver [-] failed in init 
'NoneType' object has no attribute '__getitem__' : TypeError: 'NoneType' object 
has no attribute '__getitem__'
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver Traceback (most 
recent call last):
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver   File 
"/opt/stack/vitrage/vitrage/datasources/collectd/driver.py", line 65, in 
_configur

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

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

Hi all,

As Vitrage will not participate in the Denver PTG, we decided to hold a virtual 
PTG instead. I created an etherpad[1] with a list of topics to discuss, and a 
Doodle poll[2] for selecting the date. I believe that two days will be enough. 

If you would like to participate, please add your name and preferred dates. 

[1] https://etherpad.openstack.org/p/vitrage-ptg-queens 
[2] https://doodle.com/poll/nh9czcvfayystf9u 

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] Collectd - to - Vitrage setup issues

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

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

[collectd]
config_file = /etc/vitrage/collectd_conf.yaml

Then you should restart vitrage-graph.

Let me know if it helped,
Ifat.


From: "Waines, Greg" 
Date: Wednesday, 23 August 2017 at 21:19

I am trying to get collectd to report some alarms to vitrage in a devstack 
setup,

I am using a devstack created on a late version of ocata.
And my devstack with vitrage appears to be working ok otherwise;
e.g.  I can create VMs, and raise fake alarms using “vitrage event post 
-type=compute.host.down ...” or with “aodh alarm create ... 
resource_id=instance-uuid” ... and they get reported fine in vitrage.

UNFORTUNATELY not seeing anything in vitrage from collectd, and
  don’t believe I’m seeing anything even from collectd, 
for example from the syslog output plugin.

I’ve attached the following files:   ( not sure if these get distributed on 
mailing list )
· /etc/collectd/collectd.conf   <-- do these look ok ?
· /etc/vitrage/vitrage.conf  <-- do these look ok ?
· /var/log/syslog ... around the time when I updated 
collectd.conf and vitrage.conf and restarted collectd and vitrage-graph
oQUESTIONS
•  NOTE THE FOLLOWING ERRORS IN THE SYSLOG FILE ... where do I get the 
collectd_conf.yaml file from ?  Can’t see it in the devstack files for vitrage.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.039 25962 ERROR vitrage.utils.file [-] File doesn't exist: 
/etc/vitrage/collectd_conf.yaml.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver [-] failed in init 
'NoneType' object has no attribute '__getitem__' : TypeError: 'NoneType' object 
has no attribute '__getitem__'
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver Traceback (most 
recent call last):
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver   File 
"/opt/stack/vitrage/vitrage/datasources/collectd/driver.py", line 65, in 
_configuration_mapping
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver 
collectd_config_elements = collectd_config[COLLECTD_DATASOURCE]
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver TypeError: 
'NoneType' object has no attribute '__getitem__'
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver
•
•  IT DOESN”T SEEM LIKE collectd is actually getting any events anyways ... 
shouldn’t I see some collectd events being reported in /var/log/syslog from 
some of the monitoring plugins that are loaded ?
· gregs-air:collectd-info gregwaines$ fgrep "localhost collectd" syslog
· Aug 23 13:56:07 localhost collectd[23267]: supervised by systemd, 
will signal readyness
· Aug 23 13:56:07 localhost collectd[23267]: Initialization complete, 
entering read-loop.
· Aug 23 13:56:07 localhost collectd[23267]: rrdtool plugin: Adjusting 
"RandomTimeout" to 0.000 seconds.
· Aug 23 14:09:05 localhost collectd[23267]: Exiting normally.
· Aug 23 14:09:05 localhost collectd[23267]: collectd: Stopping 5 read 
threads.
· Aug 23 14:09:05 localhost collectd[23267]: rrdtool plugin: Shutting 
down the queue thread.
· Aug 23 14:09:05 localhost collectd[23267]: collectd: Stopping 5 write 
threads.
· Aug 23 14:09:07 localhost collectd[25824]: supervised by systemd, 
will signal readyness
· Aug 23 14:09:07 localhost collectd[25824]: Initialization complete, 
entering read-loop.
· Aug 23 14:09:07 localhost collectd[25824]: rrdtool plugin: Adjusting 
"RandomTimeout" to 0.000 seconds.
·
· /etc/vitrage/templates/host_down_scenarios.yaml
· /etc/vitrage/templates/host_high_cpu_load_scenarios.yaml
oAm I suppose to have some templates that are specific to the collectd 
events/alarms that are being reported to vitrage ?

Any other suggestions on things to look at in order to understand what’s wrong ?

Greg.


__
OpenStack Development Mailing List (not for 

[openstack-dev] [vitrage][mistral] Announcing Vitrage integration with Mistral

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

Hi all,

I’d like to announce the Vitrage integration with Mistral that was developed in 
Pike cycle. 

As part of this integration, the Vitrage user can specify in a Vitrage template 
that in case a certain condition is met a Mistral workflow should be executed. 
The condition can include a combination of alarms, resources, and root cause 
analysis information. 

This capability can be used, for example, to take corrective actions in case 
Vitrage detects a failure in the system. A more powerful use case could be to 
take different corrective actions based on the different root cause alarms, as 
identified by Vitrage.

You are welcome to start using this integration and suggest new use cases. More 
information can be found here[1][2].

[1] https://docs.openstack.org/vitrage/latest/contributor/mistral-config.html 
[2] 
https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html
 

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][ptl] PTL on vacation

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

Hi,

I’m going to be on vacation between August 17th and 26th.
Idan Hefetz (idan_hefetz on IRC) will replace me while I’m away and will manage 
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

Re: [openstack-dev] [vitrage] stable/pike branch for vitrage

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

On 09/08/2017, 3:41, "Tony Breeds" <t...@bakeyournoodle.com> wrote:

On Tue, Aug 08, 2017 at 08:17:48AM +0000, Afek, Ifat (Nokia - IL/Kfar Sava) 
wrote:
> Hi,
> 
> I’m going to create stable/pike branches for vitrage and 
vitrage-dashboard tomorrow or the day after.
> If you have changes that should enter Pike, try to push them today. After 
that, we will be able to fix Pike bugs on top of stable/pike for two more weeks.
> Please do not merge changes that should enter Queens until the 
stable/pike branches are created.

Are you going to use the branch creation process in openstack/releases
or do it yourself?

Yours Tony.


Of course I’m going to use the openstack/releases process.

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] stable/pike branch for vitrage

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

Hi,

I’m going to create stable/pike branches for vitrage and vitrage-dashboard 
tomorrow or the day after.
If you have changes that should enter Pike, try to push them today. After that, 
we will be able to fix Pike bugs on top of stable/pike for two more weeks.
Please do not merge changes that should enter Queens until the stable/pike 
branches are created.

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] [elections][vitrage] Queens PTL candidacy

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

Hi All,

I would like to announce my candidacy for the Vitrage PTL for the Queens 
release.

I've been leading the Vitrage project development from the day it started, two
years ago. During this time we have made a tremendous progress, and now we have
a stable, well-known project that is running in production. We have an amazing
group of contributors and a growing community. I'm proud to say that we managed
to achieve most of our goals so far, and I hope we will continue achieving our
goals in Queens release as well.

The Pike cycle has been very productive. We added some important features like
the integration with Mistral, SNMP notifications, enhancements in the evaluator
templates (entity equivalence and 'not' operator), resource query API, and more.

As for the Queens cycle, I think we should focus on the Vitrage productization,
stability and use cases.

- Alarm History. The work on this feature has started in Pike cycle, and should
  be finished in Queens.
- Vitrage notifications. Add a REST API for registering to notifications from 
Vitrage.
- Integrate with more projects, OpenStack and external. We should enrich our
  topology with more information, so we can provide more meaningful insights on
  the status of the cloud.
- Enhance the Vitrage UI and improve its usability.
- Enrich the evaluator template language (add regular expressions, etc.), and
  support templates CRUD.
- Continue our efforts in the area of Machine Learning. Develop more algorithms
  that will provide insights about alarm correlation and causation.
- Extend the Vitrage community. I'll be happy to see more contributors joining
  our effort.

Looking forward to working with you during the Queens 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] New Vitrage releases

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

Hi,

We have new releases for Vitrage:
vitrage 1.7.0
python-vitrgeclient 1.3.0
vitrage-dashboard 1.3.0

For python-vitrageclient this is the final Pike release, as today is the final 
release date for client libraries. A stable/pike branch was created for 
critical bug fixes. The master branch can be used for Queens development only.
Regarding vitrage and vitrage-dashboard, we can continue working on the master 
branches for now and finish the Pike development.

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 notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

Thinking about this again, I understand that Vitrage is not supposed to use the 
Collectd message as part of the alarm unique key. We currently have a bug with 
clearing Collectd alarms, as a result of the Vitrage ID refactoring that 
happened in Pike. Until we fix it, you can you this patch[1] for your demo.

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

Let me know if it helped,
Ifat.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Date: Sunday, 16 July 2017 at 12:28
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

According to the vitrage-collector.log, when the alarm is cleared it has a 
different message:

Raise alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be', 
u'severity': u'WARNING', u'plugin': u'ovs_events', 'vitrage_entity_type': 
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date': 
'2017-07-14 07:31:21.405670+00:00', u'host': u'silpixa00399503', u'time': 
1500017481.363748, u'collectd_type': u'gauge', u'plugin_instance': 
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type': 
u'collectd.alarm.warning', u'message': u'link state of "qvo818dd156-be" 
interface has been changed to "DOWN"', 'resource_type': u'neutron.port'}

Clear alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be', 
u'severity': u'OK', u'plugin': u'ovs_events', 'vitrage_entity_type': 
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date': 
'2017-07-14 07:31:35.851112+00:00', u'host': u'silpixa00399503', u'time': 
1500017495.841522, u'collectd_type': u'gauge', u'plugin_instance': 
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type': 
u'collectd.alarm.ok', u'message': u'link state of "qvo818dd156-be" interface 
has been changed to "UP"', 'resource_type': u'neutron.port'}

The ‘message’ is converted to the name of the alarm, which is considered part 
of its unique key. If the message is changed from “DOWN” to “UP”, we don’t 
recognize that it’s the same alarm.
Any idea how this can be solved? Can you modify the message so it will be the 
same in both cases? Or is there another field that can uniquely identify the 
alarm?

Thanks,
Ifat.


From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 14 July 2017 at 10:56
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for fixing the issue. The patch works and I’m able to 
map the alarm to port now. Also, as a workaround, I was able to fix/resolve the 
issue by creating the static datasource (attached static_port.yaml) and 
disabling the neutron port datasource in the vitrage.conf.

Another issue that I still observe is the deleting of the alarm from the graph 
when OK collectd notification is sent (port is becomes up). Currently, it is 
not removed from the entity graph. Is it an issue in the Vitrage too? Attaching 
all logs (collected using the fix provided by you).

The 3rd issue is the Vitrage-Mistral integration, but I will describe this as a 
separate mail thread.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, July 13, 2017 5:47 PM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

I believe that this change[1] will fix your problem.

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

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 11 July 2017 at 12:48
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

According to the vitrage-collector.log, when the alarm is cleared it has a 
different message:

Raise alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be', 
u'severity': u'WARNING', u'plugin': u'ovs_events', 'vitrage_entity_type': 
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date': 
'2017-07-14 07:31:21.405670+00:00', u'host': u'silpixa00399503', u'time': 
1500017481.363748, u'collectd_type': u'gauge', u'plugin_instance': 
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type': 
u'collectd.alarm.warning', u'message': u'link state of "qvo818dd156-be" 
interface has been changed to "DOWN"', 'resource_type': u'neutron.port'}

Clear alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be', 
u'severity': u'OK', u'plugin': u'ovs_events', 'vitrage_entity_type': 
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date': 
'2017-07-14 07:31:35.851112+00:00', u'host': u'silpixa00399503', u'time': 
1500017495.841522, u'collectd_type': u'gauge', u'plugin_instance': 
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type': 
u'collectd.alarm.ok', u'message': u'link state of "qvo818dd156-be" interface 
has been changed to "UP"', 'resource_type': u'neutron.port'}

The ‘message’ is converted to the name of the alarm, which is considered part 
of its unique key. If the message is changed from “DOWN” to “UP”, we don’t 
recognize that it’s the same alarm.
Any idea how this can be solved? Can you modify the message so it will be the 
same in both cases? Or is there another field that can uniquely identify the 
alarm?

Thanks,
Ifat.


From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 14 July 2017 at 10:56
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for fixing the issue. The patch works and I’m able to 
map the alarm to port now. Also, as a workaround, I was able to fix/resolve the 
issue by creating the static datasource (attached static_port.yaml) and 
disabling the neutron port datasource in the vitrage.conf.

Another issue that I still observe is the deleting of the alarm from the graph 
when OK collectd notification is sent (port is becomes up). Currently, it is 
not removed from the entity graph. Is it an issue in the Vitrage too? Attaching 
all logs (collected using the fix provided by you).

The 3rd issue is the Vitrage-Mistral integration, but I will describe this as a 
separate mail thread.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, July 13, 2017 5:47 PM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

I believe that this change[1] will fix your problem.

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

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 11 July 2017 at 12:48
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for investigating the issue.

The port name is unique on the graph.  The ovs port name in collectd ovs_events 
plugin is identified by the ‘plugin_instance’ notification field.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Tuesday, July 11, 2017 12:00 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Tahhan, Maryam <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

I’m working on this issue.
One question: is the port name, as defined by ‘plugin_instance’, supposed to be 
unique in the g

Re: [openstack-dev] [Vitrage] Vitrage-Mistral integration problem

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

Hi Volodymyr,

The Vitrage-Mistral integration is still WIP, so it is possible that something 
was broken. I hope to finish the development in a few days, and I will 
definitely check your patch as part of it. I’ll update you once I’m done.

Best Regards and thanks for the patch,
Ifat.


From: "Mytnyk, VolodymyrX" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 14 July 2017 at 11:43
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "Tahhan, Maryam" 
Subject: [openstack-dev] [Vitrage] Vitrage-Mistral integration problem

Hi Ifat,

The Vitrage notifier fails to start with mistral plugin (applied the patch from 
https://review.openstack.org/#/c/461265/2 ) due to the following errors (see 
attached logs for more details):


2017-07-14 09:06:26.135 174776 ERROR vitrage   File 
"/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in 
_get_opt_info
2017-07-14 09:06:26.135 174776 ERROR vitrage raise NoSuchOptError(opt_name, 
group)
2017-07-14 09:06:26.135 174776 ERROR vitrage NoSuchOptError: no such option 
auth_url in group [service_credentials]


For some reason, the auth_url option in service_credentials group of 
vitrage.conf is not available for the mistral plugin. I suppose, the problem 
happens because of  
https://github.com/openstack/vitrage/commit/b744994b987e5c4466f91cb863090a5a2236e453
 commit.

The problem  can be resolved by applying the attached patch (workaround crated 
by me) that allows Vitrage to start and integrate it with Mistral properly.

Is it an issue in the Mistral plugin or some addition configuration are 
required for the Vitrage/Mistral to work together?
Thanks and Regards,
Volodymyr
__
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 notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

I believe that this change[1] will fix your problem.

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

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 11 July 2017 at 12:48
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for investigating the issue.

The port name is unique on the graph.  The ovs port name in collectd ovs_events 
plugin is identified by the ‘plugin_instance’ notification field.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Tuesday, July 11, 2017 12:00 PM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

I’m working on this issue.
One question: is the port name, as defined by ‘plugin_instance’, supposed to be 
unique in the graph? If not, then how do you uniquely identify the port (in 
collectd)?

Thanks,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, 7 July 2017 at 13:27
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

I’ve tested the template file modified by you with enabled debug for the 
Vitrage graph. See all Vitrage logs in the attachments.

Thank you!

Best Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:42 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Tahhan, Maryam <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Can you please enable debug information in vitrage.conf, restart vitrage-graph, 
and send me the vitrage-graph.log file (in the time where the alarm is raised)? 
I’ll try to understand why the alarm is not connected to the port. The 
definitions in collectd_conf.yaml seem correct.

I did find some issues with the template file – in the alarm definition, you 
specified the name of the resource instead of the name/rawtext of the alarm. 
Also, the name of the port was missing in the port definition. See the attached 
template (which I haven’t checked, but I believe should work). In any case, 
this will not fix the problem with the alarm being connected to the resource; 
it is relevant only for the next phase after we fix the first problem.

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, 7 July 2017 at 10:35
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Sorry, I forgot to attach the topology dump. Attaching it now.

Also, I’ve checked the topology, and looks like there is no relationship 
between neutron port and the alarm for some reason.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:15 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Tahhan, Maryam <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Seems like the problem is tha

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

I’m working on this issue.
One question: is the port name, as defined by ‘plugin_instance’, supposed to be 
unique in the graph? If not, then how do you uniquely identify the port (in 
collectd)?

Thanks,
Ifat.

From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 7 July 2017 at 13:27
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

I’ve tested the template file modified by you with enabled debug for the 
Vitrage graph. See all Vitrage logs in the attachments.

Thank you!

Best Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:42 PM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Can you please enable debug information in vitrage.conf, restart vitrage-graph, 
and send me the vitrage-graph.log file (in the time where the alarm is raised)? 
I’ll try to understand why the alarm is not connected to the port. The 
definitions in collectd_conf.yaml seem correct.

I did find some issues with the template file – in the alarm definition, you 
specified the name of the resource instead of the name/rawtext of the alarm. 
Also, the name of the port was missing in the port definition. See the attached 
template (which I haven’t checked, but I believe should work). In any case, 
this will not fix the problem with the alarm being connected to the resource; 
it is relevant only for the next phase after we fix the first problem.

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, 7 July 2017 at 10:35
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Sorry, I forgot to attach the topology dump. Attaching it now.

Also, I’ve checked the topology, and looks like there is no relationship 
between neutron port and the alarm for some reason.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:15 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Tahhan, Maryam <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Seems like the problem is that the alarm does not get connected to the port. In 
your collectd_conf.yaml, you should write:

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be   (collectd resource 
name)
   type: neutron.port
   name: qvo818dd156  (openstack neutron port name)

By doing this, you cause any Collectd alarm that is raised on the Collectd 
source named silpixa00399503/ovs_events/qvo818dd156-be to be connected in 
Vitrage to a resource of type neutron.port with name qvo818dd156.

Try to look in the output of ‘vitrage topology show’ (you did not attach it to 
the mail) and see the exact details of the port.

Let me know if it helped,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 6 July 2017 at 23:59
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for your help. See my response on your questions 
below:


· You see the neutron port in your entity graph, and it is

Re: [openstack-dev] [Vitrage] [aodh] Integration with doctor

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

Hi dwj,

Adding [aodh] for item #2.
Please see my answers inline.

Best Regards,
Ifat.



From: "dong.wenj...@zte.com.cn" 
Date: Friday, 7 July 2017 at 10:53


Hi,



For the integration Vitrage with doctor, I have some issues which need to be 
confirmed~  :)



1.  Notification strategies: conservative (nova->Aodh)

@Ifat

In the host_down_scenarios.yaml[1], we only set the host state as error.

But in doctor current use case, we need to call nova API 'nova reset-state' to 
set instance state as error to trigger the event alarm and notify the consumer.

Is it needed to be fix?



We need to add 'Aodh' and 'Nova' notifier plugins in Vitrage config file for 
doctor integration,  right?



[Ifat] Vitrage currently doesn’t call set instance state, but this can easily 
be added. The required steps are:

· Add “set state” action for the instances in the template yaml file

· In the Nova notifier, add a call to nova reset-state API

· The Aodh plugin is not needed in this case, since the flow is Vitrage 
-> Nova -> Aodh with no direct calls from Vitrage to Aodh





2. Notification strategies: shortcut  (inspector->Aodh)

@Ryota

Do we have any plans to change to shortcut notification?

@Ifat

If we use the shortcut notification, in the Aodh notifier plugin, maybe we need 
to create aodh alarm with 'alarm_actions'.



[Ifat] The Aodh plugin is defined as a POC, and is not very usable. We have 
discussed with the Aodh team possible enhancements (like adding an 
“external/custon alarm” in Aodh) that will enable creating an Aodh alarm from 
Vitrage, but we didn’t reach a clear conclusion. There are a few problems with 
the current implementation, related to the facts that the event-alarm does not 
exactly suit the use case; and that Vitrage may raise the same alarm several 
times for different instances. If you chose the shortcut strategy, we will have 
to open this discussion again.

Having that said, I believe that the shortcut strategy is much better for 
Vitrage. While on the conservative strategy we can support notifications to 
Nova, in the shortcut strategy we can write the Aodh plugin once and support 
all kinds of notifications (to Nova, Neutron, Heat or even external components) 
with no additional effort.





Correct me if I miss something.



[1]. 
https://github.com/openstack/vitrage/blob/master/etc/vitrage/templates.sample/host_down_scenarios.yaml



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

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Now with the file attached

From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Date: Friday, 7 July 2017 at 12:41
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Can you please enable debug information in vitrage.conf, restart vitrage-graph, 
and send me the vitrage-graph.log file (in the time where the alarm is raised)? 
I’ll try to understand why the alarm is not connected to the port. The 
definitions in collectd_conf.yaml seem correct.

I did find some issues with the template file – in the alarm definition, you 
specified the name of the resource instead of the name/rawtext of the alarm. 
Also, the name of the port was missing in the port definition. See the attached 
template (which I haven’t checked, but I believe should work). In any case, 
this will not fix the problem with the alarm being connected to the resource; 
it is relevant only for the next phase after we fix the first problem.

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 7 July 2017 at 10:35
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Sorry, I forgot to attach the topology dump. Attaching it now.

Also, I’ve checked the topology, and looks like there is no relationship 
between neutron port and the alarm for some reason.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:15 AM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Seems like the problem is that the alarm does not get connected to the port. In 
your collectd_conf.yaml, you should write:

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be   (collectd resource 
name)
   type: neutron.port
   name: qvo818dd156  (openstack neutron port name)

By doing this, you cause any Collectd alarm that is raised on the Collectd 
source named silpixa00399503/ovs_events/qvo818dd156-be to be connected in 
Vitrage to a resource of type neutron.port with name qvo818dd156.

Try to look in the output of ‘vitrage topology show’ (you did not attach it to 
the mail) and see the exact details of the port.

Let me know if it helped,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 6 July 2017 at 23:59
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for your help. See my response on your questions 
below:


· You see the neutron port in your entity graph, and it is connected to 
the VM
V:  yes, it’s correct.


· You see the alarm on the alarms view, and its resources is the 
neutron port
V: I see the alarm, sent by collectd , on the alarm page (or vitrage alarm 
list).  Not sure how to check the alarm resources?


· You see the alarm in the entity graph, connected to the neutron port
V: The Alarm is show on the entity graph, but it’s NOT connected to the neutron 
port.


· You are asking why the neutron port in the entity graph is green and 
not red?
V: The neutron port doesn’t change the color at all.

I’ve validated and tried the suggested template but unfortunately it doesn’t 
help. I still see the alarm on the graph but it is not connected to neutron 
port. Also, the neutron port desn’t change the state. Please note, that I’m 
using master branch for the Vitrage in my environment.
Also, attaching the topology dump with raised alarm.

Used configurations :


collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be
   type: neutron.port
   name: qvo818dd156  # What name we should use he

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

Can you please enable debug information in vitrage.conf, restart vitrage-graph, 
and send me the vitrage-graph.log file (in the time where the alarm is raised)? 
I’ll try to understand why the alarm is not connected to the port. The 
definitions in collectd_conf.yaml seem correct.

I did find some issues with the template file – in the alarm definition, you 
specified the name of the resource instead of the name/rawtext of the alarm. 
Also, the name of the port was missing in the port definition. See the attached 
template (which I haven’t checked, but I believe should work). In any case, 
this will not fix the problem with the alarm being connected to the resource; 
it is relevant only for the next phase after we fix the first problem.

Best Regards,
Ifat.

From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 7 July 2017 at 10:35
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Sorry, I forgot to attach the topology dump. Attaching it now.

Also, I’ve checked the topology, and looks like there is no relationship 
between neutron port and the alarm for some reason.

Thanks and Regards,
Volodymyr

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Friday, July 7, 2017 12:15 AM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Seems like the problem is that the alarm does not get connected to the port. In 
your collectd_conf.yaml, you should write:

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be   (collectd resource 
name)
   type: neutron.port
   name: qvo818dd156  (openstack neutron port name)

By doing this, you cause any Collectd alarm that is raised on the Collectd 
source named silpixa00399503/ovs_events/qvo818dd156-be to be connected in 
Vitrage to a resource of type neutron.port with name qvo818dd156.

Try to look in the output of ‘vitrage topology show’ (you did not attach it to 
the mail) and see the exact details of the port.

Let me know if it helped,
Ifat.

From: "Mytnyk, VolodymyrX" 
<volodymyrx.myt...@intel.com<mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 6 July 2017 at 23:59
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for your help. See my response on your questions 
below:


· You see the neutron port in your entity graph, and it is connected to 
the VM
V:  yes, it’s correct.


· You see the alarm on the alarms view, and its resources is the 
neutron port
V: I see the alarm, sent by collectd , on the alarm page (or vitrage alarm 
list).  Not sure how to check the alarm resources?


· You see the alarm in the entity graph, connected to the neutron port
V: The Alarm is show on the entity graph, but it’s NOT connected to the neutron 
port.


· You are asking why the neutron port in the entity graph is green and 
not red?
V: The neutron port doesn’t change the color at all.

I’ve validated and tried the suggested template but unfortunately it doesn’t 
help. I still see the alarm on the graph but it is not connected to neutron 
port. Also, the neutron port desn’t change the state. Please note, that I’m 
using master branch for the Vitrage in my environment.
Also, attaching the topology dump with raised alarm.

Used configurations :


collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be
   type: neutron.port
   name: qvo818dd156  # What name we should use here in case of 
neutron.port?

metadata:
name: ovs_interface_down
description: ovs interface down
definitions:
entities:
  - entity:
 category: ALARM
 type: collectd
 name: qvo818dd156
 template_id: collectd_alarm
  - entity:
 category: RESOURCE
 type: neutron.port
 template_id: port
relationships:
  - relationship:
 source: collectd_alarm
 relationship_type: on
 target: p

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

Seems like the problem is that the alarm does not get connected to the port. In 
your collectd_conf.yaml, you should write:

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be   (collectd resource 
name)
   type: neutron.port
   name: qvo818dd156  (openstack neutron port name)

By doing this, you cause any Collectd alarm that is raised on the Collectd 
source named silpixa00399503/ovs_events/qvo818dd156-be to be connected in 
Vitrage to a resource of type neutron.port with name qvo818dd156.

Try to look in the output of ‘vitrage topology show’ (you did not attach it to 
the mail) and see the exact details of the port.

Let me know if it helped,
Ifat.

From: "Mytnyk, VolodymyrX" <volodymyrx.myt...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 6 July 2017 at 23:59
To: "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 notification isn't shown on the 
Vitrage Graph

Hi Ifat,

Thank you for your help. See my response on your questions 
below:


· You see the neutron port in your entity graph, and it is connected to 
the VM
V:  yes, it’s correct.


· You see the alarm on the alarms view, and its resources is the 
neutron port
V: I see the alarm, sent by collectd , on the alarm page (or vitrage alarm 
list).  Not sure how to check the alarm resources?


· You see the alarm in the entity graph, connected to the neutron port
V: The Alarm is show on the entity graph, but it’s NOT connected to the neutron 
port.


· You are asking why the neutron port in the entity graph is green and 
not red?
V: The neutron port doesn’t change the color at all.

I’ve validated and tried the suggested template but unfortunately it doesn’t 
help. I still see the alarm on the graph but it is not connected to neutron 
port. Also, the neutron port desn’t change the state. Please note, that I’m 
using master branch for the Vitrage in my environment.
Also, attaching the topology dump with raised alarm.

Used configurations :


collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be
   type: neutron.port
   name: qvo818dd156  # What name we should use here in case of 
neutron.port?

metadata:
name: ovs_interface_down
description: ovs interface down
definitions:
entities:
  - entity:
 category: ALARM
 type: collectd
 name: qvo818dd156
 template_id: collectd_alarm
  - entity:
 category: RESOURCE
 type: neutron.port
 template_id: port
relationships:
  - relationship:
 source: collectd_alarm
 relationship_type: on
 target: port
 template_id: collectd_alarm_on_port
scenarios:
- scenario:
condition: collectd_alarm_on_port
actions:
 - action:
action_type: set_state
action_target:
 target: port
properties:
     state: ERROR

Thanks and Regards,
Volodymyr


From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, July 6, 2017 10:01 PM
To: 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 notification isn't shown on the 
Vitrage Graph

Hi Volodymyr,

Let me see if I understood the problem correctly. Are my assumptions right?

· You see the neutron port in your entity graph, and it is connected to 
the VM

· You see the alarm on the alarms view, and its resources is the 
neutron port

· You see the alarm in the entity graph, connected to the neutron port

· You are asking why the neutron port in the entity graph is green and 
not red?

The template that you used as an example is not what you are asking for. This 
template states that if there is an alarm on the host (in your case, the alarm 
is on the neutron port), and the host contains an instance -> raise an alarm on 
the instance and set its state to suboptimal. The template that (I think) you 
need is more simple: if there is an alarm on a neutron port, set its state to 
error.

Below is the template that I think you should use. Note that I haven’t tested 
it locally (because I don’t have the same environment as yours), so there could 
be errors. As a first step, make sure you are using the correct collectd alarm 
name (use ‘name’ and not ‘rawtext’ which is Zabbix-specific), and then run 
‘vitrage template validate’ to verify its correctness.


metadata:
 name: ovs_interface_down
 description: ovs interface is down
definitions:
 entities:
  - entity:
 category: ALARM
 type: collectd
 name: 
 template_id: collectd_alarm
  - entity:
 c

Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the Vitrage Graph

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

Hi Volodymyr,

Let me see if I understood the problem correctly. Are my assumptions right?

· You see the neutron port in your entity graph, and it is connected to 
the VM

· You see the alarm on the alarms view, and its resources is the 
neutron port

· You see the alarm in the entity graph, connected to the neutron port

· You are asking why the neutron port in the entity graph is green and 
not red?

The template that you used as an example is not what you are asking for. This 
template states that if there is an alarm on the host (in your case, the alarm 
is on the neutron port), and the host contains an instance -> raise an alarm on 
the instance and set its state to suboptimal. The template that (I think) you 
need is more simple: if there is an alarm on a neutron port, set its state to 
error.

Below is the template that I think you should use. Note that I haven’t tested 
it locally (because I don’t have the same environment as yours), so there could 
be errors. As a first step, make sure you are using the correct collectd alarm 
name (use ‘name’ and not ‘rawtext’ which is Zabbix-specific), and then run 
‘vitrage template validate’ to verify its correctness.


metadata:
 name: ovs_interface_down
 description: ovs interface is down
definitions:
 entities:
  - entity:
 category: ALARM
 type: collectd
 name: 
 template_id: collectd_alarm
  - entity:
 category: RESOURCE
 type: neutron.port
 template_id: port
 relationships:
  - relationship:
 source: collectd_alarm
 relationship_type: on
 target: port
 template_id : collectd_alarm_on_port
scenarios:
 - scenario:
condition: collectd_alarm_on_port
 - action:
action_type: set_state
action_target:
 target: port
properties:
 state: ERROR


Let me know if it helped,
Ifat.

From: "Mytnyk, VolodymyrX" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 6 July 2017 at 17:18
To: "openstack-dev@lists.openstack.org" 
Cc: "Tahhan, Maryam" 
Subject: [openstack-dev] [Vitrage] Collectd notification isn't shown on the 
Vitrage Graph

Hi All,

We are trying to configure the collectd and Vitrage service to 
raise an alarm in the Vitrage and show the alarm on the graph if a VM interface 
goes down. The collectd & collectd_vitrage plugin have been configured to send 
the notification if the OvS interface connected to VM  goes down (using OvS 
events plugin). In our case, when interface goes down, the collectd event is 
sent to Vitrage and we’re able to see it on the Alarm page. But we would like 
to show the alarm on the Entity Graph (highlighting the neutron port) but for 
some reason it doesn’t work. The 
https://github.com/openstack/vitrage/blob/master/tools/load_generator/templates/vm_0.yaml
 template has been used as a base for our scenario (changing `zabbix` 
datasource to `collectd` in the file). Our collectd datasource configuration 
(collectd_conf.yaml) looks like this (tried both variants):

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be
   type: neutron.port
   name: qvo818dd156-be

collectd:
- collectd_host: silpixa00399503/ovs_events/qvo818dd156-be
   type: nove.host
   name: silpixa00399503

Our setup configuration looks like this:

|HOST| >  |VM| ---> |NEUTRON.PORT|---> |NEUTRON.NETWOR|

Any help on the issue would be much appreciated.

Thanks and Regards,
Volodymyr
__
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] status of blueprint crud-templates

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

Hi Yujun,

We have discussed the templates CRUD in the past, but did not do a detailed 
design - we only implemented the templates validation as a first phase. You are 
more than welcome to take the blueprint.

Some issues we talked about:


· The templates should be stored in a database and not in the file 
system. Alexey Weyl is currently working on adding database support to 
Vitrage[1] as an enabler to a few blueprints, including the templates CRUD

· There should be an API to add/remove/update a template

· The templates CRUD should be supported in the Vitrage Templates view 
in Horizon as well. As a second (third?) phase, a smart template editor would 
be very helpful.

· When adding a template, it should be evaluated against all entities 
in the graph, and its ‘do’ actions should be called wherever applicable

· When removing a template, it should be evaluated against all entities 
in the graph, and its ‘undo’ actions should be called wherever applicable

· Updating a template is tricky. A naive implementation is to first 
remove the old template and then add the new one. This could cause unwanted 
results, such as a deduced alarm that is deleted and re-raised immediately 
after that. The preferred solution would be to analyze the differences between 
the old and new templates, and perform only the needed actions. This might be 
done as a second phase.

· Need to think about how the entity equivalence definitions align with 
this feature

· Note that the final release date for python-vitrageclient is July 
27th (we can continue working on vitrage core and fix bugs after that). If it 
is important for you to finish this feature in Pike, you should finish the API 
prior to this date.

[1] https://blueprints.launchpad.net/vitrage/+spec/db-support

Best regards,
Ifat.


From: "Yujun Zhang (ZTE)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 3 July 2017 at 4:49
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "wang.we...@zte.com.cn" 
Subject: [openstack-dev] [vitrage] status of blueprint crud-templates

Hi, root causers :-)

We recently starts to looking into the CRUD of templates to allow loading them 
when vitrage is up. It seems there is already one blueprint registered[1] for 
exactly the same purpose.

Is there any detailed design about it? Do you have already some ideas in mind?

[1] https://blueprints.launchpad.net/vitrage/+spec/crud-templates

--
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] Nominating Yujun Zhang to Vitrage core

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

Hi,

I added Yujun Zhang to the vitrage-core team. Yujun, Welcome ☺

Best Regards,
Ifat.

From: דני אופק <dany.of...@gmail.com>
Date: Monday, 26 June 2017 at 11:00

+1

On Mon, Jun 26, 2017 at 7:45 AM, Weyl, Alexey (Nokia - IL/Kfar Sava) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
+1

> -Original Message-----
> From: Afek, Ifat (Nokia - IL/Kfar Sava) 
> [mailto:ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>]
> Sent: Sunday, June 25, 2017 3:18 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>
> Hi,
>
> I’d like to nominate Yujun Zhang to the Vitrage core team.
>
> In the last year Yujun has made a significant contribution in Vitrage[1], both
> by adding new features and by reviewing other people’s work. He has an
> extensive knowledge of the Vitrage architecture and code, and I believe he
> would make a great addition to our team.
>
> Best Regards,
> Ifat.
>
> [1]
> https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte.com.cn+pr
> ojects:openstack/vitrage+is:merged
>

__
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 Yujun Zhang to Vitrage core

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

Hi,

I’d like to nominate Yujun Zhang to the Vitrage core team. 

In the last year Yujun has made a significant contribution in Vitrage[1], both 
by adding new features and by reviewing other people’s work. He has an 
extensive knowledge of the Vitrage architecture and code, and I believe he 
would make a great addition to our team. 

Best Regards,
Ifat.

[1] 
https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte.com.cn+projects:openstack/vitrage+is:merged


__
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] First Vitrage Pike release by the end of this week

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

Hi Yujun,

Yes, I already tagged the current Vitrage releases for Pike:
vitrage 1.6.0
python-vitrageclient 1.2.0
vitrage-dashboard 1.2.0

I also tagged the stable/ocata releases:
vitrage 1.5.2
python-vitrageclient 1.1.2
(vitrage-dashboard is the same as Ocata – 1.1.1)

You can get the releases by e.g.:
pip install vitrage=1.6.0

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: Thursday, 22 June 2017 at 5:22
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "yinli...@zte.com.cn" <yinli...@zte.com.cn>
Subject: Re: [openstack-dev] [vitrage] First Vitrage Pike release by the end of 
this week

Is it done yet?

How to fetch the released version for downstream developing?

On Tue, Jun 6, 2017 at 2:17 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi,

Pike-2 milestone is at the end of this week, and although we are not working by 
the milestones model (we are working by a cycle-with-intermediary model) we 
need to have the first Vitrage Pike release by the end of this week.

I would like to release vitrage, python-vitrageclient and vitrage-dashboard 
tomorrow. Any objections? Please let me know if you think something has to be 
changed/added before the release.

Also, we need to add release notes for the newly added features. This list 
includes (let me know if I missed something):

vitrage
• Vitrage ID
• Support ‘not’ operator in the evaluator templates
• Performance improvements
• Support entity equivalences
• SNMP notifier

python-vitrageclient
• Multi tenancy support
• Resources API

vitrage-dashboard
• Multi tenancy support – Vitrage in admin menu
• Added ‘search’ option in the entity graph

Please add a release notes file for each of your features (I’ll send an 
explanation in a separate mail), or send me a few lines of the feature’s 
description and I’ll add it.

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
--
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-dashboard] Alarm Header Blueprint

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

Looks great ☺
Since you wrote a long and impressive description, it might be worthwhile to 
push it to gerrit after all. As I said, we usually don’t push vitrage-dashboard 
specs to gerrit, so it’s really up to you.

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Thursday, 8 June 2017 at 14:58
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Heller, Alon (Nokia - IL/Kfar Sava)" <alon.hel...@nokia.com>, "Afek, Ifat 
(Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Subject: [openstack-dev] [vitrage-dashboard] Alarm Header Blueprint

I have registered a new blueprint in Vitrage-dashboard which leverages the 
proposed extensible headers of Horizon.

https://blueprints.launchpad.net/vitrage-dashboard/+spec/alarm-header

let me know your thoughts,
Greg


p.s proposed extensible header blueprint in horizon is here:
   https://blueprints.launchpad.net/horizon/+spec/extensible-header



From: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Date: Wednesday, June 7, 2017 at 4:52 AM
To: Greg Waines <greg.wai...@windriver.com>
Cc: "Heller, Alon (Nokia - IL/Kfar Sava)" <alon.hel...@nokia.com>
Subject: Re: vitrage-dashboard blueprints / specs

Hi Greg,

Adding Alon, a vitrage-dashboard core contributor.

In general, your plan seems great ☺ indeed, we don’t have many blueprints in 
vitrage-dashboard launchapd… the vitrage-dashboard team usually just implement 
the features and do code reviews without too many specs. You are welcome to 
write a blueprint-only description, and maybe send us (or add to the 
blueprintß) a UI mock.

Let us know if you need any help with that.

Best Regards,
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Date: Wednesday, 7 June 2017 at 1:33
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Subject: vitrage-dashboard blueprints / specs

Ifat,
Vitrage-dashboard seems to have very short 1-2 sentence blueprints and no spec 
files.

The Vitrage Alarm Count in Horizon Header work has turned into 3x blueprints now
- alarm-counts-api  in  Vitrage
- extensible-headers  in  Horizon <-- I am in process of 
submitting this to Horizon
- alarm-header  in  Vitrage-Dashboard

What do you suggest for the blueprint / spec for Vitrage-Dashboard ?
I could submit a blueprint using the blueprint-only template used by Horizon.

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] How to add a release notes file to Vitrage

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

Hi,

In order to add a release notes file to Vitrage, please perform the following:
$ cd /opt/stack/vitrage
$ reno new my_new_feature
Created new notes file in 
releasenotes/notes/my_new_feature-5e88573b6d99abbb.yaml

Edit the file, remove everything that you don’t need, and write 3-4 lines of 
description under ‘features’.
Example: 
https://github.com/openstack/vitrage/blob/master/releasenotes/notes/collectd-datasource-a730f06aff840c8f.yaml
Ocata release notes: https://docs.openstack.org/releasenotes/vitrage/ocata.html

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] First Vitrage Pike release by the end of this week

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

Hi,

Pike-2 milestone is at the end of this week, and although we are not working by 
the milestones model (we are working by a cycle-with-intermediary model) we 
need to have the first Vitrage Pike release by the end of this week.

I would like to release vitrage, python-vitrageclient and vitrage-dashboard 
tomorrow. Any objections? Please let me know if you think something has to be 
changed/added before the release. 

Also, we need to add release notes for the newly added features. This list 
includes (let me know if I missed something):

vitrage 
• Vitrage ID
• Support ‘not’ operator in the evaluator templates
• Performance improvements
• Support entity equivalences
• SNMP notifier

python-vitrageclient
• Multi tenancy support
• Resources API

vitrage-dashboard
• Multi tenancy support – Vitrage in admin menu
• Added ‘search’ option in the entity graph

Please add a release notes file for each of your features (I’ll send an 
explanation in a separate mail), or send me a few lines of the feature’s 
description and I’ll add it.

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] error handling

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

From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
Date: Thursday, 1 June 2017 at 18:10


On Thu, Jun 1, 2017 at 10:49 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:

So for now we agree that we need to add a UI for configuration information and 
datasources status.

Sounds good. In order to implement in UI, we shall also need api to expose them 
right?


Of course ☺

__
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] Gate issues

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

Hi,

Note that we are currently having problems with the Vitrage gate tests, related 
to python-setuptools. Other projects experience similar problems. We hope to 
fix it by the beginning of next week.

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] error handling

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

Hi Yujun,

Indeed, during the initialization phase it might be beneficial to make sure the 
user is aware of configuration problems (although I’m not sure that crashing is 
the solution). The problem is that the same code is executed both in 
initialization and later on, so telling the difference is not trivial.

So for now we agree that we need to add a UI for configuration information and 
datasources status.

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, 30 May 2017 at 11:50
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] error handling

On Tue, May 30, 2017 at 3:59 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi Yujun,

You started an interesting discussion. I think that the distinction between an 
operational error and a programmer error is correct and we should always keep 
that in mind.

I agree that having an overall design for error handling in Vitrage is a good 
idea; but I disagree that until then we better let it crash.

I think that Vitrage is made out of many pieces that don’t necessarily depend 
on one another. For example, if one datasource fails, everything else can work 
as usual – so why crash? Similarly, if one template fails to load, all other 
templates can still be activated.

This usually or always happens during initialization phase, doesn't it? It is a 
period with human inspecting and should be detected in the deployment or user 
acceptance test. So if something fails, it is better to isolate them before 
continue running, e.g. correct the invalid template, invalid data source 
configuration or remove the template and disable the data source. This is 
because such error is permanent and they won't recover automatically.

Here we need to distinguish the error that data source is temporarily 
unavailable due to network connection issue or data source not up yet. In this 
case, I agree we'd better start the rest component and perform a retry 
periodically until it recovers.

Another aspect is that the main purpose of Vitrage is to provide insights. In 
case of a failure in one datasource/template, some of the insights might be 
missing. But this will not lead to inaccurate behavior or to wrong actions 
being executed in the system. IMO, we should give the user as much information 
as possible given that we have only part of the input.

I agree, if enough insights could be provided by the running system. We can 
improve the handling of permanent error. What is even better is supporting of a 
hot load for the components and templates.

What I don't like much is sometimes errors are handled but without enough 
details. In this case, a crash with trace stack is more useful than a user 
"friendly" message like "failed to start xxx component" or "invalid 
configuration file" (I'm not talking about vitrage, it is quite common in many 
projects)

My preference is "good error handling" > "no error handling" > "bad error 
handling". Though it is difficult to distinguish what is a good error handling 
and what is bad...

Regarding the use cases that you mentioned:


  1.  invalid configuration file
[Ifat] This should depend on the specific configuration. If keystone is 
misconfigured, nothing will work of course. But if for example Zabbix is 
misconfigured, Vitrage should work and show the topology and the non-Zabbix 
alarms.

Agree. It should be handled in a different way regarding what kind of error and 
how critical it is.


  1.  failed to communicate with data source
[Ifat] I think that the error should be logged, and all other datasources 
should work as usual.

Yes, and it would be good to have a retry mechanism


  1.  malformed data from data source

[Ifat] I think that the error should be logged, and all other datasources 
should work as usual. This problem means we must modify the code in the 
datasource itself, but until then Vitrage should work, right?
Yes, I think it is possible when the data source version changes and we should 
discard the data and indicate the error. The other part should not be affected.


  1.  failed to execute an action
[Ifat] Again, that’s a problem that requires code changes; but why fail other 
actions?

What I meant here is temporary failure, e.g. when you try to mark host down but 
not able to reach it due to network connection issue or other reasons


  1.  ...
BTW, it might be a good idea to add API/UI for showing the configuration and 
the status of the datasources. We all know that errors in the log files are 
often ignored…

Sure, the errors I mentioned above is what the system operators could encounter 
even with a correct confi

Re: [openstack-dev] [vitrage] error handling

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

Hi Yujun,

You started an interesting discussion. I think that the distinction between an 
operational error and a programmer error is correct and we should always keep 
that in mind.

I agree that having an overall design for error handling in Vitrage is a good 
idea; but I disagree that until then we better let it crash.

I think that Vitrage is made out of many pieces that don’t necessarily depend 
on one another. For example, if one datasource fails, everything else can work 
as usual – so why crash? Similarly, if one template fails to load, all other 
templates can still be activated.
Another aspect is that the main purpose of Vitrage is to provide insights. In 
case of a failure in one datasource/template, some of the insights might be 
missing. But this will not lead to inaccurate behavior or to wrong actions 
being executed in the system. IMO, we should give the user as much information 
as possible given that we have only part of the input.

Regarding the use cases that you mentioned:


  1.  invalid configuration file
[Ifat] This should depend on the specific configuration. If keystone is 
misconfigured, nothing will work of course. But if for example Zabbix is 
misconfigured, Vitrage should work and show the topology and the non-Zabbix 
alarms.


  1.  failed to communicate with data source
[Ifat] I think that the error should be logged, and all other datasources 
should work as usual.


  1.  malformed data from data source

[Ifat] I think that the error should be logged, and all other datasources 
should work as usual. This problem means we must modify the code in the 
datasource itself, but until then Vitrage should work, right?


  1.  failed to execute an action
[Ifat] Again, that’s a problem that requires code changes; but why fail other 
actions?


  1.  ...

BTW, it might be a good idea to add API/UI for showing the configuration and 
the status of the datasources. We all know that errors in the log files are 
often ignored…

Best Regards,
Ifat.


From: "Yujun Zhang (ZTE)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 29 May 2017 at 16:13
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [vitrage] error handling

Brought up by a recent code review, I think it worth a thorough discussion 
about the error handling rule.

I once read an article[1] from Joyent and it impressed me on the distinguish 
between Operational errors vs. programmer errors. The article is written for 
nodejs, but the principle also applies for other programming language.

The basic rule recommended by Joyent is
Handling operational errors
(Not) handling programmer errors
There is also one rule in openstack style guide line[2] close to this idea.

[H201] Do not write except:, use except Exception: at the very least. When 
catching an exception you should be as specific so you don’t mistakenly catch 
unexpected exceptions.

I do think before we have a well designed error handling, it is better to let 
it crash. It is dangerous to hide the errors and keep the system running in 
undetermined states.

So the question is what kind of operational errors are we facing in vitrage? I 
can think of something like

  1.  invalid configuration file
  2.  failed to communicate with data source
  3.  malformed data from data source
  4.  failed to execute an action
  5.  ...
Maybe this could be the first step for the error handling design.

[1]: https://www.joyent.com/node-js/production/design/errors
[2]: https://docs.openstack.org/developer/hacking/

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

We will not hold the Vitrage weekly IRC meeting this week, as many Vitrage 
contributors will be on vacation.
We will meet again next week, on June 7th.

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 attendance in the PTG in September

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

Hi,

The next PTG (Project Team Gathering) will be held in Denver in September. We 
need to decide whether we would like to reserve a room for Vitrage, where we 
could hold design sessions for the next release.
What do you say? Are you interested in attending the 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] [nova] VM Heartbeat / Healthcheck Monitoring

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

On 16/05/2017, 4:36, "Sam P"  wrote:

Hi Greg,

 In Masakari [0] for VMHA, we have already implemented some what
similar function in masakri-monitors.
 Masakari-monitors runs on nova-compute node, and monitors the host,
process or instance failures.
 Masakari instance monitor has similar functionality with what you
have described.
 Please see [1] for more details on instance monitoring.
 [0] https://wiki.openstack.org/wiki/Masakari
 [1] 
https://github.com/openstack/masakari-monitors/tree/master/masakarimonitors/instancemonitor

 Once masakari-monitors detect failures, it will send notifications to
masakari-api to take appropriate recovery actions to recover that VM
from failures.

 
Hi Greg, Sam,

As Vitrage is about correlating alarms that come from different sources, and is 
not a monitor by itself – I think that it can benefit from information 
retrieved by both Masakari and Zabbix monitors. 

Zabbix is already integrated into Vitrage. I don’t know if there are specific 
tests for VM heartbeat, but I think it is very likely that there are. 
Regarding Masakari – looking at your documents, I believe that integrating your 
monitoring information into Vitrage could be quite straight forward. 

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] [nova] VM Heartbeat / Healthcheck Monitoring

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

Hi Greg,

If I understand correctly, you would like to add a test that checks if for 
every VM a heartbeat was retrieved in the last x seconds. Right?

Vitrage is not designed to perform such tests. Vitrage datasources retrieve 
topology (either by polling or by notifications) from services like Nova, 
Cinder, Neutron or Heat, and pass the topology to the Vitrage entity graph. In 
addition, they retrieve alarms from monitors like Aodh, Zabbix, Nagios or 
Collectd, and create these alarms in the entity graph as well. There is 
currently no place where you can check if an event arrived or not.

How about adding this test to a monitoring tool like Zabbix, and then consume 
the alarm (for a missing heartbeat) in Vitrage?

Best Regards,
Ifat.

From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 10 May 2017 at 13:24
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck 
Monitoring

Some other UPDATES on this proposal (from outside the mailing list):


· this should probably be based on an ‘image property’ rather than a 
‘flavor extraspec’,
since it requires code to be included in the guest/VM image,



· rather than use a unique virtio-serial link for the 
Heartbeat/Health-check Monitoring Messaging,
propose that we leverage the existing http://wiki.qemu.org/Features/GuestAgent

o   NOVA already supports a ‘hw_qemu_guest_agent=True’ image property
which results in NOVA setting up a virtio-serial connection to a QEMU Guest 
Agent
within the Guest/VM,

o   use this for the transport messaging layer for VM 
Heartbeating/Health-checking


With respect to ... where to propose / contribute this functionality,
Given that

· this may require very little work in NOVA (by using QEMU Guest 
Agent), and

· the fact that the primary result of VM Heartbeating / Health-checking 
is to report per-instance HB/HC status to Vitrage,
I am thinking that this would fit better simply in Vitrage.
An optional functionality enabled thru /etc/vitrage/vitrage.conf .


Comments ?
Greg.


From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Tuesday, May 9, 2017 at 1:11 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

I am looking for guidance on where to propose some “VM Heartbeat / Health-check 
Monitoring” functionality that I would like to contribute to openstack.

Briefly, “VM Heartbeat / Health-check Monitoring”

· is optionally enabled thru a Nova flavor extra-spec,

· is a service that runs on an OpenStack Compute Node,

· it sends periodic Heartbeat / Health-check Challenge Requests to a VM
over a virtio-serial-device setup between the Compute Node and the VM thru QEMU,

· on loss of heartbeat or a failed health check status will result in 
fault event, against the VM, being
reported to Vitrage thru its data-source API.

Where should I contribute this functionality ?

· put it ALL in Vitrage ... both the monitoring and the data-source 
reporting ?

· put the monitoring in Nova, and just the data source reporting in 
Vitrage ?

· other ?

Greg.





p.s. other info ...

Benefits of “VM Heartbeat / Health-check Monitoring”




· monitors health of OS and Applications INSIDE the VM

o   i.e. even just a simple Ack of the Heartbeat would validate that the OS is 
running, IO mechanisms (sockets, etc)
are working and processes are getting scheduled

· health-check status reporting can trigger and report on either 
high-level or detailed application-specific audits within the VM,




· the simple virtio-serial-device interface thru QEMU is UP very early 
in VM life cycle and is virtually always up

o   i.e. its available for reporting issues virtually all the time,

o  ... compared to reporting issues over Tenant Network to a remote 
VNFManager which relies on Ethernet and IP Networking within the VM itself and 
then any provider network and adjacent routers around the compute nodes ...




· uses a simple “Line-Delimited JSON” Format over virtio serial device 
( http://www.linux-kvm.org/page/Virtio-serial_API )

o   simple to implement protocol inside VM, in pretty much any language

o   ( although would provide reference implementation )




· provides more thorough instance monitoring than libvirt’s emulated 
hardware watchdog ( https://libvirt.org/formatdomain.html#elementsWatchdog )
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] trouble installing Nagios on devstack on ubuntu 16.04 ...

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

Hi Greg,

Sorry for not responding earlier about your Nagios problem, most of the Vitrage 
team is busy preparing to Boston.

We have already heard about the Ubuntu 16.04 issue but didn’t investigate it 
yet, so unfortunately I don’t have a solution for you at the moment. If you are 
only interested in having alarms in Vitrage, there are several options to 
achieve this.


1.   Use Yujun’s suggestion



2.   Raise a “compute down” alarm and let the Doctor datasource handle it. 
You need to:

· Make sure ‘doctor’ is defined in the list of ‘types’ in 
/etc/vitrage/vitrage.conf (if not, add it and restart vitrage-graph)

· Send an event to Vitrage using the CLI:

vitrage event post --type="compute.host.down" 
--details='{"hostname":"","source":"sample_monitor","cause":"link-down","severity":"critical","status":"down","monitor_id":"monitor-1","monitor_event_id":"123"}'



3.   Raise an Aodh alarm with constant state ‘alarm’

· Make sure ‘aodh’ is defined in the list of ‘types’ in 
/etc/vitrage/vitrage.conf (if not, add it and restart vitrage-graph)

· Call aodh CLI:

aodh alarm create --type threshold --name 'cpu_alarm' --state alarm 
--description 'CPU utilization is above 1%' -m 'cpu_util' --period 60 
--threshold 0.01 --comparison-operator gt --query 'resource_id=< instance 
uuid>' --enabled False

Hope this helps.

Best Regards,
Ifat.

From: "Yujun Zhang (ZTE)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 4 May 2017 at 1:56
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] trouble installing Nagios on devstack on 
ubuntu 16.04 ...

One easy way could be writing a scenario to raise deduced alarm based on a 
simple rule, e.g. when a host is discovered, raise an alarm saying host is up.
Waines, Greg 
>于2017年5月4日 
周四04:35写道：
I don’t think I saw any responses to this.

Alternative question ... so I’ve got vitrage up and running fine ...

What’s the easiest way to generate an alarm against a host ?   ( OTHER than 
NAGIOS, due to problem in original email ) ???

let me know any ideas,
Greg.


From: Greg Waines >
Date: Tuesday, May 2, 2017 at 9:03 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [vitrage] trouble installing Nagios on devstack on 
ubuntu 16.04 ...

Hey ... I’m working thru the ‘Vitrage - Getting Started Guide’

https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html

Was able to get vitrage up and running and enabled in horizon ... on ubuntu 
16.04 .
 ( I tried on ubuntu 14.04 and ‘./stack.sh’ warned that it had not been 
tested on trusty (14.04), I FORCE=yes it ... but it failed. )


Now trying to install Nagios in devstack
https://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html

BUT it doesn’t seem like there is an OMD package available for ubuntu 16.04 ... 
and the trusty (14.04) package won’t install due to dependency issues.



Any suggestions ?

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
--
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] Alarm Banner for Vitrage Dashboard ?

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

Hi,

I agree that there should be two blueprints, one for Horizon and one for 
Vitrage. For new APIs we usually write a spec file with the API definition, so 
other people can comment on gerrit.

Thanks, and looking forward to the blueprint ☺
Ifat.


From: "Waines, Greg" <greg.wai...@windriver.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 3 May 2017 at 14:19
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Yes, the banner would be displayed on all Horizon screens, not just Vitrage.
Agree that this would mean changes in both Horizon and some supporting code in 
Vitrage.

Would this mean 2x Blueprints ?
 - one in Horizon for the display side of the Banner, and
 - one in Vitrage to make the Alarm Counts accessible to Horizon

I think for Horizon, they only write a blueprint (and no spec file).
What is required for Vitrage ?   Just a blueprint or a spec file as well ?

I’ll definitely run the blueprint / spec file by you before submitting.

I am not attending the Boston Summit.  Although there is a handful of people 
from
Wind River attending.

thanks for the input,
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: Wednesday, May 3, 2017 at 3:02 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Hi Greg,

It sounds like a great idea.
Do you plan to show this banner in all Horizon menus (your screenshot shows 
“Compute/Instances”), or just in Vitrage? for the first option I think you 
would need to write the code in Horizon itself, not in vitrage-dashboard.

Let me know if you need any assistance with this blueprint. Also, if you are 
attending the Boston summit, we can meet and discuss it.

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: Tuesday, 2 May 2017 at 20:03
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Any opinions on whether an Alarm Banner for the Vitrage Dashboard would be a 
useful blueprint for improved usability ?

i.e. an ACTIVE Alarm Counts Banner in the Top Navbar of Horizon

· populated with the Active Alarm Counts for Critical, Major, Minor, 
Warning Severities from Vitrage,

· visible at ALL times,

· auto-refreshed relatively every 5 secs (say) ... configurable,

· selecting it takes you directly to the Vitrage -> Alarms panel

let me know if we think this would be useful to submit as a blueprint to the 
Vitrage Dashboard project,
Greg.

[cid:image001.png@01D2C431.53CEF780]
__
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] Alarm Banner for Vitrage Dashboard ?

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

Hi Greg,

It sounds like a great idea.
Do you plan to show this banner in all Horizon menus (your screenshot shows 
“Compute/Instances”), or just in Vitrage? for the first option I think you 
would need to write the code in Horizon itself, not in vitrage-dashboard.

Let me know if you need any assistance with this blueprint. Also, if you are 
attending the Boston summit, we can meet and discuss it.

Best Regards,
Ifat.

From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 2 May 2017 at 20:03
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Any opinions on whether an Alarm Banner for the Vitrage Dashboard would be a 
useful blueprint for improved usability ?

i.e. an ACTIVE Alarm Counts Banner in the Top Navbar of Horizon

· populated with the Active Alarm Counts for Critical, Major, Minor, 
Warning Severities from Vitrage,

· visible at ALL times,

· auto-refreshed relatively every 5 secs (say) ... configurable,

· selecting it takes you directly to the Vitrage -> Alarms panel

let me know if we think this would be useful to submit as a blueprint to the 
Vitrage Dashboard project,
Greg.

[cid:image001.png@01D2C3F4.58BC55E0]
__
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] The next two IRC meetings are SKIPPED

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

Hi,

Due to the Boston summit and the fact that most of Vitrage contributors are now 
busy preparing to it, we will skip the IRC meetings this week and next week. We 
will meet again on Wednesday, May 17 at 8:00 UTC.

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] Change in Vitrage ID

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

Hi,

A change that was committed today[0] modifies the Vitrage ID generation method. 
Instead of computing the vitrage-id based on the resource properties, it is now 
created as a standard OpenStack UUID.
Note that this change might affect your workflow, in case you counted on the 
previous name generation method.

Best Regards,
Ifat.

[0] https://review.openstack.org/#/c/457971/

__
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] Boston Forum Schedule

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

Hi,

The scheduled time for the Vitrage forum session is highly inconvenient, as it 
starts immediately after another Vitrage session. Is it possible to reschedule? 
Seems like Wednesday 15:30-16:10 is available – can we take it instead? 

Thanks,
Ifat.


On 10/04/2017, 12:35, "Tom Fifield"  wrote:

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. 
We have updated the topic submission site with the status of each - 
please check yours.

Please also find attached in PDF the proposed schedule for the Forum in 
Boston.


Let us know if you see major issues with it. As Thierry said in design 
summits past; "It's difficult to make too many changes at this stage as 
they quickly cascade into breaking all sorts of constraints, but we may 
still be able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on 
Thursday afternoon). These are being deliberately kept aside for the 
usual few critical topics that come up in the next few weeks and also 
for the discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the 
title, abstracts and moderators you submitted, but look forward to your 
feedback in the mean-time!

Thank you all very much for making our first Forum a success.


Regards,

Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee


__
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] Next Vitrage IRC meeting will be SKIPPED

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

Hi,

As many Vitrage developers will be on vacation next week, the IRC meeting on 
April 12 will be SKIPPED.
We will meet again on April 19.

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] Project Navigator Updates - Feedback Request

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

Hi Jimmy,

Regarding the difference between neutron.yaml and vitrage.yaml – the only thing 
I see is the different release-model. Anything else that I missed?

Thanks,
Ifat.

From: Jimmy McArthur <ji...@openstack.org>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 30 March 2017 at 19:23
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Project Navigator Updates - Feedback Request



Afek, Ifat (Nokia - IL/Kfar Sava)<mailto:ifat.a...@nokia.com>
March 30, 2017 at 11:01 AM



Under “API Versions” there should also be Newton
This is something we are currently attempting to sort out. Projects don't have 
a consistent method for listing the APIs. See previous thread.


Why aren’t the adoption and maturity specified?
In order for us to get more info about your project, we need to have the proper 
tags. Compare 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/neutron.yaml
 vs 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/vitrage.yaml
   As well as here: https://github.com/openstack/ops-tags-team/tree/master/ocata

Thanks,
Jimmy



__
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] Project Navigator Updates - Feedback Request

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

Thanks Lauren,

A few issues regarding the Vitrage page:


· Vitrage is currently listed under “Management Tools” category. As a 
Root Cause Analysis service, it doesn’t manage anything, just provides insights 
to the user (or to other projects). Can you please move it under ‘Data and 
Analytics’ category?

· Please write that Vitrage is a “Root Cause Analysis Service” without 
“RCA” and parenthesis (which are misplaced at the moment).

· Under “API Versions” there should also be Newton

· Why aren’t the adoption and maturity specified?

Thanks,
Ifat.


From: Lauren Sell 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 24 March 2017 at 19:57
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] Project Navigator Updates - Feedback Request

Hi everyone,

We’ve been talking for some time about updating the project navigator, and we 
have a draft ready to share for community feedback before we launch and 
publicize it. One of the big goals coming out of the joint TC/UC/Board meeting 
a few weeks ago[1] was to help better communicate ‘what is openstack?’ and this 
is one step in that direction.

A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services in the 
navigator
- Better categorize the projects by function in a way that makes sense to 
prospective users (this may evolve over time as we work on mapping the 
OpenStack landscape)
- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on different 
use cases to help users get started

For a bit of context, we’re working to give each OpenStack official project a 
stronger platform as we think of OpenStack as a framework of composable 
infrastructure services that can be used individually or together as a powerful 
system. This includes the project mascots (so we in effect have logos to 
promote each component separately), updates to the project navigator, and 
bringing back the “project updates” track at the Summit to give each PTL/core 
team a chance to provide an update on their project roadmap (to be recorded and 
promoted in the project navigator among other places!).

We want your feedback on the project navigator v2 before it launches. Please 
take a look at the current version on the staging site and provide feedback on 
this thread.

http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for your project 
specifically. The data is primarily pulled from TC tags[2] and Ops tags[3]. 
You’ll notice some projects have more information available than others for 
various reasons. That’s one reason we decided to downplay the maturity metric 
for now and the data on some pages is hidden. If you think your project is 
missing data, please check out the repositories and submit changes or again 
respond to this thread.

Also know this will continue to evolve and we are open to feedback. As I 
mentioned, a team that formed at the joint strategy session a few weeks ago is 
tackling how we map OpenStack projects, which may be reflected in the 
categories. And I suspect we’ll continue to build out additional tags and 
better data sources to be incorporated.

Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags

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

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" <usman...@gmail.com> 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 <javascript:;>> 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 <javascript:;>) with [vitrage] tag in
> the title, and
>> possibly get replies from other contributors as well.
    >>
>>
>>
>> Best Regards,
>>
>> Ifat.
>>
>>
>>
>>
>>
>> *From: *Muhammad Usman <us...@smartx.kr <javascript:;>>
>> *Date: *Monday, 13 March 2017 at 09:16
>>
>> *To: *"Afek, Ifat (Nokia - IL)" <ifat.a...@nokia.com <javascript:;>>
>> *Cc: *JungSu Han <js...@smartx.kr <javascript:;>>
>> *Subject: *Re: OpenStack Vitrage
>>
>>
>>
>> Hi Ifat,
>>
>> I attached our idea of extending the Vitrage Topology to include Virtual
>> switches.
>>
>> The reason, I mentioned about adding switches part in Vitrage is because
>> we experienced looping issues that effect all infrastructure resources
>> (i.e. physical host as well as vm's) performance. Therefore, it's
> important
>> to monitor the virtual switches as well to assist overall monitoring

Re: [openstack-dev] [vitrage] vitrage Resource API

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

Hi dwj,

The resource API is something that we planned on implementing, but eventually 
didn’t do that.

Best Regards,
Ifat.

From: "dong.wenj...@zte.com.cn" <dong.wenj...@zte.com.cn>
Date: Tuesday, 21 March 2017 at 02:45
To: "trinath.soman...@nxp.com" <trinath.soman...@nxp.com>
Cc: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>, 
"Afek, Ifat (Nokia - IL/Kfar Sava)" <ifat.a...@nokia.com>
Subject: Re: [openstack-dev] [vitrage] vitrage Resource API


No, in the implemention of these APIs．

see 
https://github.com/openstack/vitrage/blob/master/vitrage/api/controllers/v1/resource.py#L47






Original Mail
Sender:  ＜trinath.soman...@nxp.com＞;
To:  ＜openstack-dev@lists.openstack.org＞; ＜openstack-dev@lists.openstack.org＞;
Date: 2017/03/21 00:50
Subject: Re: [openstack-dev] [vitrage] vitrage Resource API


In tests?
Get Outlook for iOS<https://aka.ms/o0ukef>


From: dong.wenj...@zte.com.cn ＜dong.wenj...@zte.com.cn＞
Sent: Monday, March 20, 2017 2:49:57 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] vitrage Resource API


Hi All,



I noticed that the APIs of `resource list` and `resource show`  were mocked.

Is  there any backgroud for the mock or the API is not necessary?



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

Re: [openstack-dev] [vitrage] what is "API to register on Vitrage notificaitons"

[Afek, Ifat (Nokia - IL)]

Yes, that’s the right blueprint.

Best Regards,
Ifat.

From: "Yujun Zhang (ZTE)" 
Date: Thursday, 16 March 2017 at 18:14

Hi root causers

I want to confirm some detail about one subject in vitrage Pike roadmap

· API to register on Vitrage notificaitons

Is it linked to blueprint 
https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications ?

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