[openstack-dev] [javascript] remove IIFE in js-generator-openstack

Hi, JavaScript Ninjas, Currently, all scripts in js-generator-openstack is written in IIFE form which is not necessary for nodejs project but introduce some trouble to jsdoc. What do you think we remove all the IIFE wrapper? A partial m

Re: [openstack-dev] [daisycloud-core] IRC Meeting Log 20160722

Why not try the meeting bot to record the IRC log and archive it automatically? See http://eavesdrop.openstack.org/ -- Yujun On Fri, Jul 22, 2016 at 5:40 PM wrote: > Hi Team, > > About the daisy4nfv things we did not have time to discuss, I want to add > that: I thought in the future, when we m

Re: [openstack-dev] [devstack][vitrage] some compress error when deploy OS

aster/vitragedashboard/static/vendor/dagre-d3/demo/arrows.html#L8 Currently we can make a work around by removing the demo pages from the python lib. $ sudo mv /opt/stack/vitrage-dashboard/vitragedashboard/static/vendor/dagre-d3/demo/ dagre-d3-demo.backup Could vitrage and devstack team have a look at it? --

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

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

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

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 > Date: Friday, 5 August 2

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 "client.host

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

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

r better understanding 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 [mailt

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

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 >

[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': u'string

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

n '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 Augus

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

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 wrote: > It seems

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

o 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

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

[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

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

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

[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 http://developer.op

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

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

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

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

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) wrote: > Hi Yujun, > > This is something that we need to handle. You can open a bug about it. > > Best Regards, > Ifat. > > From

[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

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

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

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

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

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

Yujun Zhang 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.7.8 on Aug > 18, 2016)

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] 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 have some thoughts re

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

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

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

at 2:53 PM 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 > > >

[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 (no

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

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 Mailing

[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] inspecting external openstack environment

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 Development Mailing List (not for

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 your comments are welcom

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

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

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

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

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

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

Agree. It seems I missed the first clause in Alexeys 2nd proposal. `get_all` in constructor could be a good solution. On Mon, Nov 28, 2016 at 12:18 PM wrote: Hi all, Maybe call the get_all method in the AodhDriver constructor and cache all the alarms is a simple way. BR, dwj *Yujun

[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 `datetime_uti

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

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

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

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

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

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

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

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

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

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

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,

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 A

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

d thus 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 Developmen

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

tion. > > 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: [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 vitrage.

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 act

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 is

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

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

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

obsolete, but from 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, w

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

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 suspect I just made things more comp

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 t

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

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

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 wrote: > Yes, if we consider the Vitrage scenario evaluator a

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 scenario templates (or > dir

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

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 serious project for machine

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

ten. > > > > I’ll be happy to also hear Elisha’s opinion about it, as he created this > mechanism. > > > > Best Regards, > > Ifat. > > > > > > *From: *Yujun Zhang > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions

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

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 > *Date: *Sunday, 15 January 2017 at 17:53 > > > > About fault and alarm,

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

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

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 you think? > > > > Ifa

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 cor

[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

[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 `static_

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

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

[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

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

mail.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 patch works as expected. Is there any way I can make f

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

Failures in new submissions. That might be an issue. Get Outlook for iOS <https://aka.ms/o0ukef> -- *From:* Yujun Zhang (ZTE) *Sent:* Monday, March 20, 2017 8:47:30 AM *To:* shak...@gmail.com *Cc:* OpenStack Development Mailing List (not for usage questions

[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] [vitrage] trouble installing Nagios on devstack on ubuntu 16.04 ...

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

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 configuration and not related to software bugs. Display them in UI would be very helpful. The log f

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

[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

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

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

[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

  1   2   >