[openstack-dev] [vitrage] Barcelona design sessions

Hi, As discussed in our IRC meeting today, you are welcome to suggest topics for vitrage design sessions in Barcelona: https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions Thanks, Ifat. __ OpenStack

[openstack-dev] [vitrage] PTL candidacy

Hi All, I would like to announce my candidacy to continue as Vitrage PTL for the Ocata release. I've been leading the Vitrage project development from the day it started, in Mitaka. During this time our team has made tremendous progress, and now we have a fully-functional RCA service. The

[openstack-dev] [vitrage] Vitrage IRC meeting - SKIPPED this week

Hi, Vitrage meeting today will be SKIPPED. We will meet again next week, on September 20. Thanks, Ifat. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [vitrage] inspecting external openstack environment

t; > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [vitrage] inspecting external openstack > environment > > > > One additional question about openstack datasource. > > > > Is it possible to conn

Re: [openstack-dev] [vitrage] inspecting external openstack environment

: Re: [openstack-dev] [vitrage] inspecting external openstack environment One additional question about openstack datasource. Is it possible to connect multiple openstack data sources, furthermore, different version of openstack (liberty, newton), at the same time? To monitor existing systems

Re: [openstack-dev] [vitrage] inspecting external openstack environment

> From: Yujun Zhang >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> Date: Tuesday, 30 August 2016 at 10:06 >> To: "OpenStack Development Mailing List (not for usage questions)" >> Subject: [openstack-dev] [vitrage] inspectin

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

From: Yujun Zhang Date: Monday, 5 September 2016 at 13:14 On Mon, Sep 5, 2016 at 5:49 PM Afek, Ifat (Nokia - IL) > wrote: From: Yujun Zhang Date: Friday, 2 September 2016 at 08:47 ... Cool. Just please note that you can’t push it to master at

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

On Mon, Sep 5, 2016 at 5:49 PM Afek, Ifat (Nokia - IL) wrote: > > From: Yujun Zhang > Date: Friday, 2 September 2016 at 08:47 > ... > Cool. > Just please note that you can’t push it to master at the moment, as we are > in feature freeze. Once stable/newton is created we will

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

From: Yujun Zhang Date: Friday, 2 September 2016 at 08:47 On Fri, Sep 2, 2016 at 2:44 AM Afek, Ifat (Nokia - IL) > wrote: I think you have a point. We can indeed use the templates definitions for the static datasources as well. If agreed by the

[openstack-dev] [vitrage] can't get nagios datasource

Hi Vitrages, I deploy the Vitrage OS env with the latest code using devstack. And I config the Nagios and start my_site. I used the config two months ago, it works. But this time, it can not get the nagio datasource. In the function `prepare_service`, i add some log to print

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

On Fri, Sep 2, 2016 at 2:44 AM Afek, Ifat (Nokia - IL) wrote: > I think you have a point. We can indeed use the templates definitions for > the static datasources as well. > If agreed by the team, I will get started to implement it. @all, please share your opinions. All

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

. Best Regards, Ifat. From: Yujun Zhang Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 1 September 2016 at 05:51 To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [vitrag

Re: [openstack-dev] [vitrage] inspecting external openstack environment

enstack > > BTW, what is the version of this openstack environment? > > Best Regards, > Ifat. > > From: Yujun Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday, 30 August 2016 at 10:06 > To: "OpenStack Developme

[openstack-dev] [vitrage] blueprint proposal: graph log inspector

Dear all, I proposed a new blueprint about graph log inspector on gerrit [1] and would be happy to receive everyone's comments. [1] https://review.openstack.org/#/c/364140

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

> > > If you need help understanding how to work with the mock_sync, let me know. > > > > Elisha > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Tuesday, August 30, 2016 9:59 AM > > > *To:* OpenStack Development Maili

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi, Ifat, The static configuration contains definitions of `entities` and *their* `relationships while the scenario templates contains a definition section which includes `entities` and `relationships` *between them*. An outline of these two format are as below. static configuration - entities

Re: [openstack-dev] [vitrage] inspecting external openstack environment

Subject: [openstack-dev] [vitrage] inspecting external openstack environment My purpose is to inspect an **existing** openstack environment with vitrage. Do I have to install vitrage on the target environment or it can be done by proper conf

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi Yujun, From: Yujun Zhang Date: Monday, 29 August 2016 at 11:59 entities: - type: switch name: switch-1 id: switch-1 # should be same as name state: available relationships: - type: nova.host name: host-1 id: host-1 # should be same as name is_source:

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

isha From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Tuesday, August 30, 2016 9:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources I added a new key 'is_source' to static physical config

[openstack-dev] [vitrage] inspecting external openstack environment

My purpose is to inspect an **existing** openstack environment with vitrage. Do I have to install vitrage on the target environment or it can be done by proper configuration? -- Yujun __ OpenStack Development Mailing List

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [vitrage] relationship_type in > static_datasources > > > > Patch work in progress [1] but local test fails [2]. > > > > It seems to be caused by the mock_sync. > > >

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

What is the problem you are running into with mock_sync? Elisha From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Tuesday, August 30, 2016 5:09 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] relationship_type

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

direction_source, and use the new definition from the yaml >> file here to decide the edge direction. >> >> >> >> Is it ok? >> >> >> >> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] >> *Sent:* Friday, August 26, 2016 4:22 AM >&g

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

t 26, 2016 4:22 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [vitrage] relationship_type in > static_datasources > > > > Lost in the code...It seems the datasource just construct the entities and > send them

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Thanks for replying. See my comments inline. On Sun, Aug 28, 2016 at 8:02 PM Afek, Ifat (Nokia - IL) wrote: > Hi Yujun, > > Regarding the validation – I agree that we should implement it in another > way, but as a first stage I think you can just remove it. > OK > If you

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

to decide the edge direction. Is it ok? From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Friday, August 26, 2016 4:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources Lost in the code

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

> Alexey > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Thursday, August 25, 2016 4:50 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [vitrage] relationship_type in > static_datasources > > > &

Re: [openstack-dev] [vitrage] entity graph layout

ugust 2016 at 10:52 To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [vitrage] entity graph layout After the first investigation, I think cytoscape might be too heavy. There would be lots of refactoring work to migrate all functions to new

Re: [openstack-dev] [vitrage] entity graph layout

After the first investigation, I think cytoscape might be too heavy. There would be lots of refactoring work to migrate all functions to new library. So I would suspend this proposal for now. However, it seems the layout could be improved by adjusting the parameters applied to force layout, e.g.

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources Hi, Ifat, I searched for edge_labels in the project. It seems it is validated only in `vitrage/evaluator/template_validation/template_syntax_validator.py`. Where is such restriction

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi, Ifat, I searched for edge_labels in the project. It seems it is validated only in `vitrage/evaluator/template_validation/template_syntax_validator.py`. Where is such restriction applied in static_datasources? -- Yujun On Wed, Aug 24, 2016 at 3:19 PM Afek, Ifat (Nokia - IL)

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi Yujun, Indeed, we have some restrictions on the relationship types that can be used in the static datasources. I think we should remove these restrictions, and allow any kind of relationship type. Best regards, Ifat. From: Yujun Zhang Date: Monday, 22 August 2016 at 08:37 I'm following

Re: [openstack-dev] [vitrage] entity graph layout

I'm considering to use Cytoscape.js [1] to improve the layout for entity graph view. Cytoscape.js is a graph theory (a.k.a. network) library for analysis and visualisation which under active maintenance (latest release 2.7.8 on Aug 18, 2016) [2], while the current library d3-dagre [3] is declared

[openstack-dev] [vitrage] relationship_type in static_datasources

I'm following the sample configuration in docs [1] to verify how static datasources works. It seems `backup` relationship is not displayed in the entity graph view and neither is it included in topology show. There is an enumeration for edge labels [2]. Should relationship in static datasource

Re: [openstack-dev] [vitrage] gate-vitrage-dsvm-api FAILURE

, August 19, 2016 8:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [vitrage] gate-vitrage-dsvm-api FAILURE I submit a simple patch for additional log message but the CI job keeps failure even after recheck. It seems some configuration files are missing

[openstack-dev] [vitrage] gate-vitrage-dsvm-api FAILURE

I submit a simple patch for additional log message but the CI job keeps failure even after recheck. It seems some configuration files are missing according to the console log [2]. Does anybody encountering the same issue as me? ``` 2016-08-18 19:59:15.155472

Re: [openstack-dev] [vitrage][vitrage-dashboard] cropped entity information

t; Ifat. > > From: Yujun Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 17 August 2016 at 07:08 > To: "OpenStack Development Mailing List (not for usage questions)" > Subject: [openstack-dev] [vitrage][vitrage-da

Re: [openstack-dev] [vitrage] valid source and target for add_causal_relationship

com> wrote: > Yes, it should be limited to ‘ALARM’ > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Wednesday, August 17, 2016 9:00 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [vi

Re: [openstack-dev] [vitrage][vitrage-dashboard] cropped entity information

(not for usage questions)" Subject: [openstack-dev] [vitrage][vitrage-dashboard] cropped entity information In the topology view, the content of entity information is sometimes cropped when there are too many rows. Is there a way to peek the cropped content? [

Re: [openstack-dev] [vitrage] reference a type of alarm in template

nt Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [vitrage] reference a type of alarm in template Thanks a lot Liat. So if `name` is omitted, all alarms from that source will match the entity. Otherwise the `name` is checked. The property mapped to `name` is defined i

Re: [openstack-dev] [vitrage] reference a type of alarm in template

: nagios_alarm > > > > Best regards, > > Liat > > > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Wednesday, August 17, 2016 3:51 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-d

Re: [openstack-dev] [vitrage] valid source and target for add_causal_relationship

Yes, it should be limited to ‘ALARM’ From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Wednesday, August 17, 2016 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [vitrage] valid source and target for add_causal_relationship The issue

Re: [openstack-dev] [vitrage] reference a type of alarm in template

: ALARM type: nagios template_id: nagios_alarm Best regards, Liat From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Wednesday, August 17, 2016 3:51 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] reference

[openstack-dev] [vitrage] valid source and target for add_causal_relationship

The issue comes from my carelessness that creating a causal relationship between two relationship instead of entities [1]. But it seems not be detected by the template validator. I wonder what could be a valid `source` and `target` for causal relationship? Should it be limited to `ALARM`? [1]

[openstack-dev] [vitrage][vitrage-dashboard] cropped entity information

In the topology view, the content of entity information is sometimes cropped when there are too many rows. Is there a way to peek the cropped content? [image: xbm5sl.jpg] -- Yujun __ OpenStack Development Mailing List (not

Re: [openstack-dev] [vitrage] reference a type of alarm in template

entation for the in the future. > > > > Best regards, > > Liat Har-Tal > > > > > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Tuesday, August 16, 2016 5:18 AM > > > *To:* OpenStack Development Mailing List (not for usage

[openstack-dev] [vitrage] add the resource to the alarm notification

Hi, I'm writing an alarm notifier that need to get from vitrage graph the resource along with the alarm. So I've added blueprint : https://blueprints.launchpad.net/vitrage/+spec/add-resource-to-alarm-notification I've also wrote the code that implement it. And I'm ready to commit it. BR

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

023 > > F: +972 9 793 3036 > > [image: download] > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Monday, August 15, 2016 8:49 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org>; Rosen

Re: [openstack-dev] [vitrage] reference a type of alarm in template

Zhang [mailto:zhangyujun+...@gmail.com] Sent: Tuesday, August 16, 2016 5:18 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] reference a type of alarm in template Hi, Elisha There is no `name` in the template [1], and type is not one

[openstack-dev] [vitrage][vitrage-dashboard] missing icon/font in alarm list under material theme

The alarm list is not displaying some icon/font correctly under Material theme. See attached screenshots. Could anybody have a look? Tracked in https://bugs.launchpad.net/vitrage-dashboard/+bug/1613574 Material: [image: Screen Shot 2016-08-16 at 3.14.26 PM.png] × [image: Screen Shot 2016-08-16

[openstack-dev] [vitrage] Vitrage weekly IRC meeting is SKIPPED

Hi, Vitrage IRC meeting tomorrow (Aug 17) will be SKIPPED, as many Vitrage contributors are away. Thanks, Ifat. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

hang [mailto:zhangyujun+...@gmail.com] Sent: Monday, August 15, 2016 8:49 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>; Rosensweig, Elisha (Nokia - IL) <elisha.rosensw...@nokia.com> Subject: Re: [openstack-dev] [vitrage] scenario evalu

Re: [openstack-dev] [vitrage] reference a type of alarm in template

From: Yujun Zhang <zhangyujun+...@gmail.com> Sent: Aug 15, 2016 16:10 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [vitrage] reference a type of alarm in template I have a question on how to reference a type of alarm in template

[openstack-dev] [vitrage] reference a type of alarm in template

I have a question on how to reference a type of alarm in template so that we can build scenarios. In the template sample [1], an alarm entity has three keys: `category`, `type` and `template_id`. It seems `type` is the only information to distinguish different alarms. However, when an alarm is

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

o > the analysis. > > Elisha > > > From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] > > Sent: Thursday, August 11, 2016 5:49 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [vitrage] scenario eval

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

: Yujun Zhang [mailto:zhangyujun+...@gmail.com] > Sent: Thursday, August 11, 2016 5:49 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [vitrage] scenario evaluator not enabled by > default > > Sorry for having put a url from for

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

Sorry for having put a url from forked repo. It should be https://github.com/openstack/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff-6f1a277a2f6e9a567b38d646f19728bcL36 But the content is the same -- Yujun On Thu, Aug 11, 2016 at 10:43 PM Yujun Zhang

[openstack-dev] [vitrage] scenario evaluator not enabled by default

It seems the scenario evaluator is not enabled when vitrage is started in devstack installer. I dig a bit in the history, it seems the default value for the evaluator is changed from True to False in a history commit [1]. Is it breaking the starting of evaluator or I have missed some steps to

Re: [openstack-dev] [vitrage] aodh datasource properties

OK, I have assigned myself for this issue and hope to resolve it soon. -- Yujun On Thu, Aug 11, 2016 at 6:30 PM Afek, Ifat (Nokia - IL) wrote: > Hi Yujun, > > There are few ways to create Aodh alarms. You are referring to > event-alarms, and I believe you are right about

Re: [openstack-dev] [vitrage] aodh datasource properties

Hi Yujun, There are few ways to create Aodh alarms. You are referring to event-alarms, and I believe you are right about the bug. Note, however, that for threshold-alarm, the resource_id appears without the “traits” prefix, so Vitrage Aodh datasource should be able to handle both cases. An

[openstack-dev] [vitrage] aodh datasource properties

It seems the aodh properties definition in vitrage [1] is not consistent with the latest ceilometer spec [2]. The response_id is now encapsulated in `traits` and we must prepend the scope in query to make it a valid alarm condition, e.g. `query: [{u'field': u'traits.resource_id', u'type':

Re: [openstack-dev] [vitrage] spec for datasource

From: Yujun Zhang Date: Tuesday, 9 August 2016 at 14:48 1. How do I register a new datasource in an existing system? [yujunz] It seems to be in https://github.com/openstack/vitrage/blob/master/vitrage/datasources/__init__.py Not exactly. This file defines the default datasources to be used. You

Re: [openstack-dev] [vitrage] spec for datasource

Hi lfat, Thank you for the answers, please see my reply inline. On Tue, Aug 9, 2016 at 6:51 PM Afek, Ifat (Nokia - IL) wrote: > Hi Yujun, > > Please see my answers below. > > Best Regards, > Ifat. > > From: Yujun Zhang > Date: Tuesday, 9 August 2016 at 12:06 > > > For

Re: [openstack-dev] [vitrage] spec for datasource

, 2016 12:07 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [vitrage] spec for datasource Hi, Eylon, It is not decided yet what datasources will be required. But we may assume there will be bot

Re: [openstack-dev] [vitrage] spec for datasource

Hi Yujun, Please see my answers below. Best Regards, Ifat. From: Yujun Zhang Date: Tuesday, 9 August 2016 at 12:06 For proprietary datasource, I'm considering to adapt the api to common protocol/interface, e.g. RESTful, SNMP and etc and I wish to know how to add support for these interface.

[openstack-dev] [vitrage] questions and answers

Dear all, Below is a digest of conversation between me and vitrage PTL lfat. It clarifies some of my questions and I hope it will also be useful for developers who are watching vitrage project. - relationship between entities Examples of "on" and "contain" given in document. But not

Re: [openstack-dev] [vitrage] spec for datasource

.@gmail.com] > Sent: Tuesday, August 09, 2016 10:22 AM > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [vitrage] spec for datasource > > Dear all, > > Is there a guide on how to unders

Re: [openstack-dev] [vitrage] spec for datasource

the new datasource to vitrage upstream or leave it private ? Eylon From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Tuesday, August 09, 2016 10:22 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [v

[openstack-dev] [vitrage] spec for datasource

Dear all, Is there a guide on how to understand the design of datasource? I want to extend the existing one and also try to create a custom datasource from scratch. Some documents are found in https://github.com/openstack/vitrage-specs and datasource seems to be related to synchronizer but I

Re: [openstack-dev] [vitrage] entity graph layout

There is no such blueprint at the moment. You are more than welcome to add one, in case you have some ideas for improvements. Ifat. From: Yujun Zhang Date: Monday, 8 August 2016 at 09:21 Great, it works. But it would be better if we could improve the default layout. Is there any blueprint in

Re: [openstack-dev] [vitrage] entity graph layout

Great, it works. But it would be better if we could improve the default layout. Is there any blueprint in progress? -- Yujun On Sun, Aug 7, 2016 at 1:09 PM Afek, Ifat (Nokia - IL) wrote: > Hi, > > It is possible to adjust the layout of the graph. You can double-click on > a

Re: [openstack-dev] [vitrage] entity graph layout

Hi, It is possible to adjust the layout of the graph. You can double-click on a vertex and it will remain pinned to its place. You can then move the pinned vertices around to adjust the graph layout. Hope it helped, and let us know if you need additional help with your demo. Best Regards,

Re: [openstack-dev] [vitrage] entity graph layout

forgot to attach a screenshot. See below[image: Screen Shot 2016-08-05 at 2.28.56 PM.png] × On Fri, Aug 5, 2016 at 2:32 PM Yujun Zhang wrote: > Hi, all, > > I'm building a demo of vitrage. The dynamic entity graph looks > interesting. > > But when more entities are

[openstack-dev] [vitrage] entity graph layout

Hi, all, I'm building a demo of vitrage. The dynamic entity graph looks interesting. But when more entities are added, things becomes crowded and the links screw over each other. Dragging the items will not help much. Is it possible to adjust the layout so I can get a more regular/stable tree

[openstack-dev] [vitrage] Vitrage Mascot Selection

Hi, According to the poll we had, Vitrage mascot will be a Giraffe - it's skin looks like a vitrage, and it sees everything from above. Now we should think of how we would like to illustrate it. Should we color the entire Giraffe like a Vitrage? Maybe just part of it? other ideas? (an

Re: [openstack-dev] [vitrage] Vitrage Mascot Selection

> -Original Message- > From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com] > Sent: Wednesday, July 13, 2016 11:53 AM > > Hi, > > As we discussed in the IRC meeting today, we should select a Mascot for > Vitrage project. > > Please add your suggestions in the etherpad below: >

[openstack-dev] [vitrage] Vitrage Mascot Selection

Hi, As we discussed in the IRC meeting today, we should select a Mascot for Vitrage project. Please add your suggestions in the etherpad below: https://etherpad.openstack.org/p/vitrage-mascot We need to select 3-5 leading suggestions, send them to OpenStack representative for evaluation, and

Re: [openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

On 24/06/2016 9:58 AM, Julien Danjou wrote: > On Thu, Jun 23 2016, Afek, Ifat (Nokia - IL) wrote: > >> I understood that during Aodh-Vitrage design session in Austin, you had a >> discussion about Vitrage need for notifications about Aodh alarm state >> changes. >> Did you have a chance to

Re: [openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

On Thu, Jun 23 2016, Afek, Ifat (Nokia - IL) wrote: > I understood that during Aodh-Vitrage design session in Austin, you had a > discussion about Vitrage need for notifications about Aodh alarm state > changes. > Did you have a chance to think about it since, and to check how this can be >

[openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

Hi Julien, Gordon, I understood that during Aodh-Vitrage design session in Austin, you had a discussion about Vitrage need for notifications about Aodh alarm state changes. Did you have a chance to think about it since, and to check how this can be done? Thanks, Ifat.

[openstack-dev] [vitrage] Template Structure Change

Hi All, Please note that from today the id field in metadata section is renamed and from now it is called name. After updating your code, you should also update the templates which you are using in your setups. Any question is welcome, Liat

[openstack-dev] [vitrage] Vitrage meeting on June 22 - SKIPPED

Hi, Vitrage weekly meeting on June 22 will be skipped due to OPNFV summit. We will meet again on June 29. Thanks, Ifat. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [vitrage] multi-tenancy in Vitrage

Hi, During the discussion about accepting vitrage into the big tent[1], there was a concern raised by a few people regarding whether Vitrage is suitable for a public cloud. They were bothered that allowing each user to see the entire cloud topology is not suitable in such environments. It is

[openstack-dev] [vitrage] Vitrage is now an official OpenStack project

Hi, Great news - Vitrage (OpenStack RCA service) was accepted into the big tent yesterday, in the TC IRC meeting[1]. Thanks to everyone who participated in this huge effort of creating a whole project from scratch in a little more than 6 months. Now, with the wind in our sails, we invite

Re: [openstack-dev] [vitrage] vitrage - how much links model in API is permanent?

Good to know. Thank you very much. -Original Message- From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com] Sent: Tuesday, May 31, 2016 11:15 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [opensta

Re: [openstack-dev] [vitrage] vitrage - how much links model in API is permanent?

Hi Eylon, This dictionary is created by NetworkX, and is not about to be changed. You can definitely rely on this API to be permanent. And we should make sure we have a tempest test for verifying it. Best regards, Ifat. > -Original Message- > From: Malin, Eylon (Nokia - IL)

[openstack-dev] [vitrage] vitrage - how much links model in API is permanent?

Hi, While calling /v1/topology/ the response has links part, which is list of dicts. Each dict have the following properties : is_deleted : Boolean key : string relationship_type : string source : int target : int How much that structure is permanent ?

Re: [openstack-dev] [vitrage] failed to show graph topology on graph without root

+...@gmail.com] Sent: Thursday, May 26, 2016 6:00 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [vitrage] failed to show graph topology on graph without root Hi Eylon, Could you please provide the

Re: [openstack-dev] [vitrage] failed to show graph topology on graph without root

Hi Eylon, Could you please provide the query and data which will reproduce this issue? -- Yujun On Thu, May 26, 2016 at 10:44 PM Malin, Eylon (Nokia - IL) < eylon.ma...@nokia.com> wrote: > Hi all, > > I use vitrage without any root graph (In my case there is no root). > Until few days ago I

[openstack-dev] [vitrage] failed to show graph topology on graph without root

Hi all, I use vitrage without any root graph (In my case there is no root). Until few days ago I was able to request topology of type graph with no problems. But I can't, I got 404, and the log says it can't find openstack.cluster node. I think it have the problems since these commits :

Re: [openstack-dev] [vitrage] input erroneous `vitrage_id` in `vitrage rca show`API or `vitrage topology show` API

...@zte.com.cn Cc: Shamir, Ohad (Nokia - IL) Subject: Re: [openstack-dev] [vitrage] input erroneous `vitrage_id` in `vitrage rca show`API or `vitrage topology show` API Hi, all I'm not sure if vitrage follows the RESTful API. In RESTful API, it is reasonable to return 404 error when the requested resource

Re: [openstack-dev] [vitrage] input erroneous `vitrage_id` in `vitrage rca show`API or `vitrage topology show` API

Hi, all I'm not sure if vitrage follows the RESTful API. In RESTful API, it is reasonable to return 404 error when the requested resource does not exist. If we want to display a friendly message, it could be implemented in front end. The backend API should remain simple and consistent since we

Re: [openstack-dev] [vitrage] input erroneous `vitrage_id` in `vitrage rca show`API or `vitrage topology show` API

Hi dwj, I'm passing the question (and answer) to openstack mailing list. You are right. In case of an invalid vitrage id, we should not return HTTP 404 error. I think the correct behavior would be to return a nice error message like "Alarm XYZ does not exist". You can open a bug about it.

[openstack-dev] [vitrage] Vitrage meeting on May 25 - SKIPPED

Hi, Vitrage weekly meeting on May 25 will be skipped, as many Vitrage developers won't be able to attend. We will meet next week as usual. Thanks, Ifat. __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [vitrage] Yaml file validation for Static Physical datasource

No problem, I'll do that :) From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com] Sent: Wednesday, May 18, 2016 11:25 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [vitrage] Yaml file validation for Static Physical datasource Hi Liat, I have noticed that you

Re: [openstack-dev] [vitrage] Normalized Resource State

t;tomer.a...@alcatel-lucent.com> Subject: Re: [openstack-dev] [vitrage] Normalized Resource State > -Original Message- > From: EXT Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com] > > Sounds good Ifat and Eylon. > > Maybe we only need to think of a more general

Re: [openstack-dev] [vitrage] Normalized Resource State

> -Original Message- > From: EXT Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com] > > Sounds good Ifat and Eylon. > > Maybe we only need to think of a more general name for TERMINATING > state (something that will include all end transient states). > > > -Original

[openstack-dev] [vitrage] Yaml file validation for Static Physical datasource

Hi Liat, I have noticed that you are working on the validation of the templates yaml files. Can you please write the validation for the static physical yaml files as well? Alexey __ OpenStack Development Mailing List (not

Re: [openstack-dev] [vitrage] Normalized Resource State

6 6:29 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Amir, Tomer (Nokia - IL) > Subject: Re: [openstack-dev] [vitrage] Normalized Resource State > > > -Original Message- > > From: EXT Malin, Eylon (Nokia - IL) [mailto:eylon.ma...@nokia.com] >

Re: [openstack-dev] [vitrage] Normalized Resource State

> -Original Message- > From: EXT Malin, Eylon (Nokia - IL) [mailto:eylon.ma...@nokia.com] > Sent: Monday, May 16, 2016 6:09 PM > > Hi all, > > Aggregated_state can has only values from NormalizedResourceState which > is constant enum. > Currently the NormalizedResourceState has these

<    1   2   3   4   5   >