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

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

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

Forgot to paste the link to the related code: https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61 On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com> wrote: > Hi root causers > > I have

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

ata source is not defined 2. data source defined but state config not exist 3. data source defined, state config exist but the state is not found. Could somebody shed some light on it? -- Yujun Zhang __ OpenStack Development Ma

Re: [openstack-dev] [infra] support graphviz in document publishing

python.org/pypi/sphinxcontrib-blockdiag > > Might be worth looking at if you want something simpler than graphviz > and to not depend on it. > Really nice diagram and syntax. I will surely consider it for so

Re: [openstack-dev] [infra] support graphviz in document publishing

anual/drivers.html#package-requirements Thanks Andreas. Besides the dependency you mentioned, I just realized that we need also to add the extension to sphinx conf[1] to make it effective. https://review.openstack.org/#/c/518196/8/doc/source/conf.

[openstack-dev] [infra] support graphviz in document publishing

/proposals/aggregate-equivalent-alarms.rst [2]: http://www.sphinx-doc.org/en/stable/ext/graphviz.html -- Yujun Zhang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

[openstack-dev] [oslo][oslo.middleware] when will next release arrive

://review.openstack.org/#/c/487454/ -- 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

[openstack-dev] [vitrage] status of blueprint crud-templates

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

Re: [openstack-dev] [vitrage] Nominating Yujun Zhang to Vitrage core

Thanks all. It is my pleasure to work with you in Vitrage project :-) -- Yujun On Mon, Jun 26, 2017 at 4:34 PM Afek, Ifat (Nokia - IL/Kfar Sava) < ifat.a...@nokia.com> wrote: > Hi, > > > > I added Yujun Zhang to the vitrage-core team. Yujun, Welcome J > >

Re: [openstack-dev] [vitrage] First Vitrage Pike release by the end of this week

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

Re: [openstack-dev] [vitrage] Gate issues

; > > > Best Regards, > > Ifat. > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.o

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

pose them right? -- 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] error handling

sources. 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 configuration and not related to software bugs. Display them in UI would be very helpful. The log files are more for the en

[openstack-dev] [vitrage] 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

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

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

[openstack-dev] [vitrage] use case repository

://wiki.openstack.org/wiki/Vitrage/RoadMap#Very_important -- Yujun Zhang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org

Re: [openstack-dev] [stackalytics] user correction seems not effective

wrote: Jenkins is throwing some Failures in new submissions. That might be an issue. Get Outlook for iOS <https://aka.ms/o0ukef> ------ *From:* Yujun Zhang (ZTE) <zhangyujun+...@gmail.com> *Sent:* Monday, March 20, 2017 8:47:30 AM *To:* shak...@gmail.c

[openstack-dev] [stackalytics] user correction seems not effective

t;zhangyujun.d...@gmail.com>", "zhangyu...@gmail.com <zhangyu...@gmail.com>"*, "284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn", "zhang.yuj...@zte.com.cn"]}} The email address in red should be removed if the

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

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

Re: [openstack-dev] [vitrage] New Vitrage project mascot

Not remembering the original design. This one looks good to me :-) On Sun, Jan 29, 2017 at 8:18 PM Afek, Ifat (Nokia - IL) wrote: > Hi, > > > > This is the new draft of our Giraffe mascot. The illustrators tried to > make its skin look more like stained glass. > > What do

[openstack-dev] [stackalytics] how to remove obsoleted email address from one id

Stackalytics cores: I reported a bug on ownership of commits in stackalytics months ago[1]. It seems to be caused by obsoleted email address in user default data. In `user_processor`, it merges email addresses from `default_data.json` to runtime storage[2]. It seems removing email address from

[openstack-dev] [infra][mitmstack] initial member of mitmstack groups

Hi, Infra team, Could you please help add me as initial member in mitmstack-core and mitmstack-release ? Thank you. -- Yujun

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

Sounds good. Have you created an etherpad page for collecting topics, Ifat? On Mon, Jan 16, 2017 at 10:43 PM Afek, Ifat (Nokia - IL) < ifat.a...@nokia.com> wrote: > > > *From: *Yujun Zhang <zhangyujun+...@gmail.com> > *Date: *Sunday, 15 January 2017 at 17:53 > > &

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

About fault and alarm, what I was thinking about the causal/deducing chain in root cause analysis. Fault state means the resource is not fully functional and it is evaluated by related indicators. There are alarms on events like power loss or measurands like CPU high, memory low, temperature

Re: [openstack-dev] [vitrage] code organization for trace generator and

hat I’ve recently written. > > > > I’ll be happy to also hear Elisha’s opinion about it, as he created this > mechanism. > > > > Best Regards, > > Ifat. > > > > > > *From: *Yujun Zhang <zhangyujun+...@gmail.com> > *Reply-To: *"OpenSta

Re: [openstack-dev] [machine learning] Question: Why there is no serious project for machine learning ?

Not sure what you mean by serious. Maybe you could have a look at Meteos[1]. It is a young project but surely focuses on machine learning. [1]: https://wiki.openstack.org/wiki/Meteos On Fri, Jan 13, 2017 at 3:57 PM 严超 wrote: > Hi, all, > I'm wondering if there is a

[openstack-dev] [vitrage] code organization for trace generator and

Hi, Root Causers In the implementation of static driver unit test, the most difficult part I've encountered is the mock driver and trace generator. Is there any particular reason to put all mock driver and transformer specs in the same file `trace_generator.py` and `mock_driver.py`? Would it be

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

Hi, Ifat You comments is quite right. See my additional explanation inline. On Thu, Jan 12, 2017 at 5:12 PM Afek, Ifat (Nokia - IL) wrote: > > > One possible solution would be introducing a high level (abstract) > template from users view. Then convert it to Vitrage

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

I have just realized abstract alarm is not a good term. What I was talking about is *fault* and *alarm*. Fault is what actually happens, and alarm is how it is detected (or deduced). On Wed, Jan 11, 2017 at 5:13 PM Yujun Zhang <zhangyujun+...@gmail.com> wrote: > Yes, if we consider th

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

the real > Nagios alarm is just one example of the more general case of two monitors > reporting the same alarm. > > Don’t you think so? > > > > *From: *Yujun Zhang <zhangyujun+...@gmail.com> > > > *Reply-To: *"OpenStack Development Mailing List (not for u

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

Hi, Ifat If I understand it correctly, your concerns are mainly on same alarm from different monitor, but not "suspect" status as discussed in another thread. On Tue, Jan 10, 2017 at 10:21 PM Afek, Ifat (Nokia - IL) < ifat.a...@nokia.com> wrote: Hi Yinliyin, At first I thought that changing

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

the suspect switch_alarm, > or keep it? If you would like to delete it, it will require supporting > ‘not’ in the template condition. > > > > Personally I would go for option 2b, but I will be happy to hear your > thoughts about it. > > > > Hope I helped, but I sus

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

m what I see at the moment and can be > seen in the code, it won't enter the to the 2.c.1 because the neighbor > vertex already exists and the neighbor vertex isn't defined as > is_delete=false. > > That is a problem, and I have a solution for the problem, which I need > to make sure that

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU] [vitrage]how touseplaceholder vertex

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Sunday, January 08, 2017 5:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] [vitrage]how touseplaceholder vertex Hi, Alexey On Sun, Jan 8, 2017 a

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] [vitrage] how touseplaceholder vertex

Hi, Alexey On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi Yujun, > > A relationship is defined by the following trio: source id, target id and > a label on the edge. > In the processor, I add only edges that doesn't exists. > Currently the vertex

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

reason could be event delay or lost. Instead of waiting for snapshot service to update the host status, we want to run a diagnostic action to check it initiatively. In this case, we want to set the upstream (host) of a confirmed alarm (instance) to "suspect" and trigger an diagnostic

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

The two questions raised by YinLiYin is actually one, i.e. *how to enrich the alarm properties *that can be used as an condition in root cause deducing. Both 'suspect' or 'datasource' are additional information that may be referred as a condition in general fault model, a.k.a. scenario in

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] [vitrage] how to useplaceholder vertex

Hope it answers everything. > > BR, > Alexey > > > > From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] > Sent: Thursday, January 05, 2017 2:32 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] [vit

Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] how to use placeholder vertex

s it is ok that for each main entity we will create its > neighbors and connect between them. There is no need for any distinguish > due to that. > > > From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] > Sent: Wednesday, December 14, 2016 5:00 PM > To: OpenStack Development Mai

Re: [openstack-dev] 答复: RE: Re: [ALU] [Vitrage] vitrage tempest job config

It seems the file is truncated on Github preview. It stops at openstack/security-specs If you check the raw file[1], you will find entry of openstack/vitrage [1]: https://raw.githubusercontent.com/openstack-infra/project-config/master/zuul/layout.yaml [image: Screen Shot 2017-01-05 at 9.11.08

Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

e a placeholder is to call the placeholder method of > the correct transformer using the transformers array that each transformer > class has. > > > > I hope this helps. > > > > Alexey > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Wednesday,

[openstack-dev] [vitrage] how to use placeholder vertex

Hi, root causers (assuming this nickname has been agreed) It seems the placeholder is created for every neighbor of an entity[1]. I'm not sure what will happen if the neighbor entity has been created before. Will the graph utility handle it? Or we need to check the existence in transformer and

Re: [openstack-dev] [vitrage] how to use mock driver

the regex generation support a few months > ago, since the python package we were using – exrex – was not one that > OpenStack supported. > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Tuesday, December 13, 2016 8:32 AM > > > *To:* OpenStack Developmen

Re: [openstack-dev] [vitrage] how to use mock driver

les in > test_scenario_evaluator.py. > > > > Elisha > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Monday, December 12, 2016 8:23 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> >

[openstack-dev] [vitrage] how to use mock driver

Is there any documentation on how to use mock driver for unit testing? It seems it generates fake events from json spec but what is the different between - `xxx_snapshot_X.json` and `xxx_dynamic_X.json` - `xxx_S` and `xxx_D`

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] [vitrage] datasource driverreturnsentities only?

h transformer knows exactly how to build it’s own > placeholder). > > > > Alexey > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Monday, December 05, 2016 2:38 AM > > > *To:* OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] datasource driver returnsentities only?

eed to refer to that), for example: “RESOURCE:nova.host:12345678”. > > > > So in this way all you need to know about the other entity is it’s > and it’s . > > > > BR, > > Alexey > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Se

Re: [openstack-dev] [ALU] [vitrage] datasource driver returns entities only?

ts on, and that is how > we decide to connect it to the correct host. > > > > I think it is ok that the event of static (from driver to the processor) > will contain for each entity it neighbors that it is supposed to be > connected to. > > > > BR, > > Ale

[openstack-dev] [vitrage] datasource driver returns entities only?

During the implementation of static datasource driver[1], I got a question on the return format of `get_all` method. If I understand correctly, it should return a list of entities to be sent to the queue. Does it infer that the relationship should be embedded in entity, just like the legacy

[openstack-dev] [vitrage] entity_type in make_pickleable

Several properties are added to entity in `DriverBase.make_pickleable`[1] but the existence check is only applied in `_add_entity_type`. I think it may not be necessary after we prepended vitrage namespace[2]. I could not think of a scenario to let user shadow the built-in `entity_type`. Is

Re: [openstack-dev] [ALU] [vitrage] common vs utils

Ready for review https://review.openstack.org/#/c/404517/ On Mon, Nov 28, 2016 at 5:50 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Sounds good to me J > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Monday, November 28, 2016 10

Re: [openstack-dev] Suspected SPAM - Re: Suspected SPAM - [vitrage] datasources terminology

LGTM On Tue, Nov 29, 2016 at 6:38 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Sounds good to me :) > > From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com] > Sent: Tuesday, November 29, 2016 11:23 AM > To: OpenStack Development Mailing List (not for usage questions) >

[openstack-dev] [vitrage] common vs utils

Currently, we have `common/utils.py`, `common/file_utils.py` and an empty module `utils` in `vitrage`. In my understanding, `common` means *common to vitrage package* and utils are more *general purpose utility* functions. Would it better that we move `utils.py`, `file_utils.py` and

Re: [openstack-dev] [vitrage] about aodh alarm notification

le way. BR, dwj *Yujun Zhang <zhangyujun+...@gmail.com <zhangyujun%2b...@gmail.com>>* 2016-11-28 11:23 收件人 "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org>, "dong.wenj...@zte.com.cn" < dong.we

Re: [openstack-dev] [vitrage] about aodh alarm notification

Hi, Alexey My comments inline. On Mon, Nov 28, 2016 at 1:52 AM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi Dong, > > > > I can think of 2 solutions for this problem: > > 1. We can talk with the AODH developers and check if they can add > additional data for the aodh

Re: [openstack-dev] [vitrage]bp:static-datasource-config-formatworking items

On Tue, Nov 15, 2016 at 8:44 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Ok, sounds good. > > We need to understand what is the common way in openstack to work with > deprecated code. > Maybe it could be discussed in next weekly meeting. Anybody who has experience on it please

Re: [openstack-dev] [ALU] [vitrage] bp:static-datasource-config-formatworking items

Hi, Alexey I plan to split the implementation to several steps, because it will take weeks to complete. I'm afraid it would be too big a patch to review if I submit all changes in one patch set. Instead I want to get comments as earlier as possible. Each submit will be covered by additional unit

[openstack-dev] [vitrage] bp:static-datasource-config-format working items

Hi folks. I have just started working on the blueprint about static datasource config format[1]. The planned working items are as following. 1. create new datasource `static` to parse new configuration format 2. parse old configuration format in `static` with a proxy to existing

[openstack-dev] [javascript] developer meetup at Barcelona Summit

Dear JavaScript Ninjas, We are planning a meetup of JavaScript developers in Barcelona Summit. It is scheduled on Tuesday and we may talk about the javascript SDK for openstack and the first MVP. Anyone who is interested in it please contact me. -- Yujun

Re: [openstack-dev] [Vitrage] Installation

Hi, Paul, You may check whether all required services have been started normally. Below is the example output from an instance created by https://github.com/openzero-zte/vitrage-demo The topology service is on `vitrage-graph` while the alarm service is on `vitrage-notifier` if I understand it

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

tion for how to add a new datasource: > > > https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst > > > > Alexey > > > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Wednesday, September 07, 2016 6:08 AM > &g

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

or Vitrage >> in >>the existing openstack >>- For notifications, you need to connect Vitrage to the oslo bus of >>the existing openstack >> >> BTW, what is the version of this openstack environment? >> >> Best Regards, >> Ifat. >> >

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

On Mon, Sep 5, 2016 at 5:49 PM Afek, Ifat (Nokia - IL) <ifat.a...@nokia.com> 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

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

[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

Rosensweig, Elisha (Nokia - IL) < elisha.rosensw...@nokia.com> wrote: > 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 > > > *

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. I'm still looking into it. Any help would be appreciated. [1] https://review.openstack.org/#/c/362525 [2] http://pastebin.com/iepqxUAP On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang <zhangyu

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

In method: _create_neighbor, remove the usage of method > _find_relation_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, Augus

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

yl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi Yujun, > > > > You can find the names of the lables in the constants.py file. > > > > In addition, the restriction on the physical_static datasource is done in > it’s driver.py. > > >

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

Yujun Zhang <zhangyujun+...@gmail.com> wrote: > 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.

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

t.a...@nokia.com> wrote: > 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: Y

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

/cytoscape.js [3] https://github.com/cpettitt/dagre-d3 On Mon, Aug 8, 2016 at 2:34 PM Afek, Ifat (Nokia - IL) <ifat.a...@nokia.com> wrote: > 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.

[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

[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

Reported at https://bugs.launchpad.net/vitrage-dashboard/+bug/1614585 -- Yujun On Thu, Aug 18, 2016 at 9:44 PM Afek, Ifat (Nokia - IL) <ifat.a...@nokia.com> wrote: > Hi Yujun, > > This is something that we need to handle. You can open a bug about it. > > Best Regards, &g

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] reference a type of alarm in template

ory use > > template_id: nagios_alarm_2 > > > > *Example 2*: definition for a general alarm from specific data source > > > > - entity: > > category: ALARM > > type: nagios > > template_id

[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

[openstack-dev] [javascript] library api reference publishing

As an action from the javascript meeting, below is the summary of how to integrate jsdoc [1] generated api reference with sphinx document. Feel free to comment and discuss in today's meeting. - findings - openstack api ref is dedicated to describe RESTful interface

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

ry fields are: > > · template_id > > · category > > All the other fields are optional and they are designed so that you more > accurately define the entity. > > Each alarm data source has its own set of fields you can use – we will add > docum

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

you are looking for in > “consistency_enforcer.py”. > > Hope it helps. > > > > > > *Nofar Schnider* > > Senior Software Engineer > > Applications & Analytics, Nokia > > 16 Atir Yeda > > Kfar Saba, Israel 44643 > > M: +972 52 4326

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

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

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 <zhangyujun+...@gmail.

[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

me 'cpu_alarm' --description 'CPU > utilization is above 70%' -m 'cpu_util' --period 60 --threshold 0.7 > --comparison-operator gt --query > 'resource_id=5f6db701-19d6-4a98-895b-8094f2bd7304' > > Hope it helped, > Ifat. > > From: Yujun Zhang > Date: Thursday, 11 August 2016 at 12:36

[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

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) <ifat.a...@nokia.com> wrote: > Hi Yujun, > > Please see my answers below. > > Best Regards, > Ifat. > > From: Yujun Zhang > Date

[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

nderstanding the case, do you want to add new datasource > that would be contributed to openstack, or is it propriety one ? > I'm meaning do you plan to push the new datasource to vitrage upstream or > leave it private ? > > Eylon > > > From: Yujun Zhang [mailto:zhangyujun+..

[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] [nova] [vitrage] Nova host list api - performance

Is the data transfer compressed? If there are lots of repeated pattern in the payload, compressing the content may result in great improvement in performance. -- Yujun On Mon, Aug 8, 2016 at 3:19 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi, > > I am running the

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

an 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, > Ifat. > > > From: Yujun Zhang

  1   2   >