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

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Congrats ☺

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Monday, June 26, 2017 11:31 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Suspected SPAM - Re: [openstack-dev] [vitrage] Nominating Yujun Zhang 
to Vitrage core

Hi,

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

Best Regards,
Ifat.

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

+1

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

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

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

[openstack-dev] [Vitrage] New service in Vitrage

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi,

We have added a new service to Vitrage, called vitrage-collector.

Vitrage-collector is part of our HA (High Availability) solution.

At the moment, until we'll finish to write the history, after restarting the 
vitrage-graph you have to restart the vitrage-collector as well.

BR,
Alexey :)
__
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] Suspected SPAM - [vitrage] Nominating Yujun Zhang to Vitrage core

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

+1

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

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi,

The gate problem was solved.

The problem wasn’t with the setuptools, but with a change that was pushed to 
the project-config (a change that was also pushed to other projects 
configurations as well).

Due to that problem the vitrage was enabled twice.

BR,
Alexey Weyl

From: Yujun Zhang (ZTE) [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, June 01, 2017 6:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

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

We have encountered similar issue also in OPNFV.

It seems to be a problem of setuptools 36.0.0 and it is now removed from pypi. 
Hope it resolves the vitrage gate tests as well.

See discussion in https://github.com/pypa/setuptools/issues/1042


On Thu, Jun 1, 2017 at 11:08 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
> wrote:
Hi,

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

Best Regards,
Ifat.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
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] Suspected SPAM - Re: [vitrage] about "is_admin" in ctx

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi,

Yes the ‘is_admin_project’ represent the tenant.

I have tried to use many different users which are part of the admin, alt_demo, 
nova, vitrage, new_tenant that I have created and they all returned the 
is_admin_project=True.

At the moment as I said only the admin user will be able to see the 
all-tenants, although this is not correct, and there are other users has the 
permissions to see all-tenants as well.

We have added a new tab in horizon under the admin tab, where those who has 
permission to see that tab can see the vitrages all-tenants.

In our case only the Admin at the moment will actually see all the entities.

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Wednesday, May 17, 2017 12:24 PM
To: Weyl, Alexey (Nokia - IL/Kfar Sava) <alexey.w...@nokia.com>
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev]Suspected SPAM - Re: [vitrage] about  "is_admin" in 
ctx


Hi Alexey,

Currently we use 'is_admin' as 'is_admin_project'[1], right?

I think the 'is_admin_project' represent the tenant , not be related to user.

So why 'is_admin_project' alaways return 'True' with all of the user and 
tenants is the issue.

What about a user which is not ＇admin' but have the 'admin' role?

Should the user with 'admin' role see all  all-tenants?


[1] 
https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94



Ｔｈａｎｋｓ~



BR,

dwj




Original Mail
Sender:  ＜alexey.w...@nokia.com＞;
To:  ＜openstack-dev@lists.openstack.org＞;
Date: 2017/05/15 22:49
Subject: Re: [openstack-dev]Suspected SPAM - Re:  [vitrage] about  "is_admin" 
in ctx


Wenjuan,

Sorry it took me so long to answer due to the Boston Summit.

After making some more checks in order to make it sure, the results are the 
following:

1.  The context that we use has 2 properties regarding admin (is_admin, 
is_admin_project).

2.  The is_admin property regards whether the user that has done the 
inquiry is the admin or not. So the only way it is True is if the user is  
admin.

3.  The is_admin_project I thought will represent the tenant of the user, 
but from all of the user and tenants that I have used, it laways returned  me 
True.

4.  Due to that I have decided to use the is_admin property in the context 
to indicate whether the user can see all-tenants or not.

5.  This is not a perfect solution because also users such as 
nova/cinder/all project names seems to be able to see the admin tab. In our 
case  what will happen is that although in the UI we have the admin tab for 
those users, the data we will show in the vitrage tab is not of all the tenants 
but this specific tenant.

Alexey

From: Weyl, Alexey (Nokia - IL/Kfar Sava) [mailto:alexey.w...@nokia.com]
Sent: Tuesday, April 25, 2017 3:10 PM
To: OpenStack Development Mailing List (not for usage questions) 
＜openstack-dev@lists.openstack.org＞
Subject: Suspected SPAM - Re: [openstack-dev] [vitrage] about  "is_admin" in ctx

Hi Wenjuan,

This is a good question, I need to check it a bit more thoroughly.

It’s just that at the moment we are preparing for the Boston Openstack Summit 
and thus it will take me a bit more time to answer that.

Sorry for the delay.

Alexey ☺

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Friday, April 21, 2017 11:08 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] about  "is_admin" in ctx


Hi all,

I'm a little confused about the "is_amdin" in ctx.

From the 
hook(https://github.com/openstack/vitrage/blob/master/vitrage/api/hooks.py#L73),
  "is_admin" means admin user,.

But we define the macro as "admin project"( 
https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94
  ). But in my opinion,  it should be the admin role. Correct me if i'm wrong 
:).



BR,

dwj










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

Re: [openstack-dev] Suspected SPAM - Re: [vitrage] about "is_admin" in ctx

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi Wenjuan,

Sorry it took me so long to answer due to the Boston Summit.

After making some more checks in order to make it sure, the results are the 
following:

1.   The context that we use has 2 properties regarding admin (is_admin, 
is_admin_project).

2.   The is_admin property regards whether the user that has done the 
inquiry is the admin or not. So the only way it is True is if the user is admin.

3.   The is_admin_project I thought will represent the tenant of the user, 
but from all of the user and tenants that I have used, it laways returned me 
True.

4.   Due to that I have decided to use the is_admin property in the context 
to indicate whether the user can see all-tenants or not.

5.   This is not a perfect solution because also users such as 
nova/cinder/all project names seems to be able to see the admin tab. In our 
case what will happen is that although in the UI we have the admin tab for 
those users, the data we will show in the vitrage tab is not of all the tenants 
but this specific tenant.

Alexey

From: Weyl, Alexey (Nokia - IL/Kfar Sava) [mailto:alexey.w...@nokia.com]
Sent: Tuesday, April 25, 2017 3:10 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Suspected SPAM - Re: [openstack-dev] [vitrage] about  "is_admin" in ctx

Hi Wenjuan,

This is a good question, I need to check it a bit more thoroughly.

It’s just that at the moment we are preparing for the Boston Openstack Summit 
and thus it will take me a bit more time to answer that.

Sorry for the delay.

Alexey ☺

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Friday, April 21, 2017 11:08 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] about  "is_admin" in ctx


Hi all,

I'm a little confused about the "is_amdin" in ctx.

From the 
hook(https://github.com/openstack/vitrage/blob/master/vitrage/api/hooks.py#L73),
 "is_admin" means admin user,.

But we define the macro as "admin project"( 
https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94
 ). But in my opinion,  it should be the admin role. Correct me if i'm wrong :).



BR,

dwj






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

Re: [openstack-dev] [vitrage] about "is_admin" in ctx

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi Wenjuan,

This is a good question, I need to check it a bit more thoroughly.

It’s just that at the moment we are preparing for the Boston Openstack Summit 
and thus it will take me a bit more time to answer that.

Sorry for the delay.

Alexey ☺

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Friday, April 21, 2017 11:08 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about  "is_admin" in ctx


Hi all,

I'm a little confused about the "is_amdin" in ctx.

From the 
hook(https://github.com/openstack/vitrage/blob/master/vitrage/api/hooks.py#L73),
 "is_admin" means admin user,.

But we define the macro as "admin project"( 
https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94
 ). But in my opinion,  it should be the admin role. Correct me if i'm wrong :).



BR,

dwj






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

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

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi Dong,

At the beginning that API was a mock, and then when the Vitrage started to 
work, we haven’t implemented the API and thus we can’t show an API in the 
client that doesn’t work.

In order to implement that API it also needs to support Multi tenancy.

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Tuesday, March 21, 2017 2:46 AM
To: trinath.soman...@nxp.com
Cc: openstack-dev@lists.openstack.org
Subject: [ALU] Re: [openstack-dev] [vitrage] vitrage Resource API


No, in the implemention of these APIs．

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






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


Outlook for iOS


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


Hi All,



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

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



BR,

dwj








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

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

[Weyl, Alexey (Nokia - IL)]

I see, you want 2 edges between PC_a and PC_b.

In order to model such a use case you need to use the action 
update_relationship in the processor.

You can it in the following way:
   1. in the transformer create PC_a -> PC_b in the regular way, by using the 
action create_entity or update_entity.
   2. when a new relationship arrives, that should arrive with a new label you 
can model the transformer to return an action update_relationship and thus a 
new edge will be added between those entities.

Hope it helps,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, January 10, 2017 7:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: 
[ALU]Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

Great! So let's come back to my original question on redundant link.

Before: PC_a is connected to PC_b with Cable
After: PC_a is connected to PC_b with Cable AND Wi-Fi

How to we model this? 
1. Create a new edge labeled "Cable and Wi-Fi" ? 
2. Assign a structured label like ["Cable", "Wi-Fi"] to the edge?
3. Create two edges, one labeled "Cable", the other labeled "Wi-Fi"?
--
Yujun

On Mon, Jan 9, 2017 at 6:44 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,

After some more checks, I found out the current code will handle your case as 
well, because it will go into the 2.c.1.

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
>
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>    a. finds all the valid_edges and the obsolete_edges
>    b. deletes all the obsolete edges from the graph
>    c. connects the valid edges to the graph:
>       iterates over all the neighbors, and for each neighbor checks:
>       1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>          a. Update this vertex in the graph.
>          b. check if the edge doesn't exist yet and if so then add the
> edge.
>
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is 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, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
>
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
>
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
> <alexey.w...@nokia.com> wrote:
> That’s not what I mean.
>
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
>
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
>
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
>
> Alexey
>
> 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 at 2:50 PM Weyl, Alexey (Nokia - IL)
> <

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

After some more checks, I found out the current code will handle your case as 
well, because it will go into the 2.c.1.

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
> 
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>a. finds all the valid_edges and the obsolete_edges
>b. deletes all the obsolete edges from the graph
>c. connects the valid edges to the graph:
>   iterates over all the neighbors, and for each neighbor checks:
>   1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>  a. Update this vertex in the graph.
>  b. check if the edge doesn't exist yet and if so then add the
> edge.
> 
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is 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, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
> 
> Alexey
> 
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
> 
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
> 
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
> <alexey.w...@nokia.com> wrote:
> That’s not what I mean.
> 
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
> 
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
> 
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
> 
> Alexey
> 
> 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 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 mapping to entity, and the edge is mapping to
> relationship.
> 
> So do you mean that we should update the label if the relationship
> between two entities changes? e.g. we change the link between two PC's
> from cable to Wi-Fi.
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

What will happen is the following:
We have a connection between PC_a and PC_b with label Cable.
Now a new event arrives and the transformer builds the following trio:
(Vertex_A, Neighbors((Vertex_B, Edge), UPDATE)
This transformed data arrives to the processor that goes to the UPDATE action:
1. Updates the Vertex_A (PC_a) properties in the graph.
2. Calls the _update_neighbors method: 
   a. finds all the valid_edges and the obsolete_edges
   b. deletes all the obsolete edges from the graph
   c. connects the valid edges to the graph:
  iterates over all the neighbors, and for each neighbor checks:
  1. if the neighbor_vertex doesn't exist yet or if the is_deleted property 
of the neighbor_vertex is false then:
 a. Update this vertex in the graph.
 b. check if the edge doesn't exist yet and if so then add the edge.

In your case the edge the edge 'Cable' will be deleted from the graph because 
it is 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, which I need to make 
sure that it ruin anything else because everything goes through the processor.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Monday, January 09, 2017 10:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: 
[ALU][vitrage]how touseplaceholder vertex

Thanks Alexey. Could you explain a bit more detail based on the example in 
comments below?

On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
That’s not what I mean.

When some data is changed in a some vertices, their event is pushed to the 
event queue, and thus the correct transformer is called.
We update the data of the current vertex, and for each neighbor that we created 
in the transformer, we check the following:
if the neighbor vertex doesn't exist yet or if the id_deleted property of the 
neighbor vertex is false, then update the vertex in the graph. Then it checks 
if the edge is not in the graph yet, then it adds it.

Before: PC_a is linked to PC_b with Cable
After: PC_a is linked to PC_b with Wi-Fi

So this will results in a removal of original edge (labeled Cable) and adding 
of new edge (labeled Wi-Fi) . Is that correct?

Alexey

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 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 mapping to entity, and the edge is mapping to 
relationship. 

So do you mean that we should update the label if the relationship between two 
entities changes? e.g. we change the link between two PC's from cable to Wi-Fi.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

That’s not what I mean.

When some data is changed in a some vertices, their event is pushed to the 
event queue, and thus the correct transformer is called.
We update the data of the current vertex, and for each neighbor that we created 
in the transformer, we check the following:
if the neighbor vertex doesn't exist yet or if the id_deleted property of the 
neighbor vertex is false, then update the vertex in the graph. Then it checks 
if the edge is not in the graph yet, then it adds it.

Alexey

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 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 mapping to entity, and the edge is mapping to 
relationship. 

So do you mean that we should update the label if the relationship between two 
entities changes? e.g. we change the link between two PC's from cable to Wi-Fi.
__
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] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] [vitrage] how touseplaceholder vertex

[Weyl, Alexey (Nokia - IL)]

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.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Thursday, January 05, 2017 4:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] [vitrage] how 
touseplaceholder vertex

A follow up question on relationships.
On Thu, Jan 5, 2017 at 9:59 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,

Lets see.

1. There is no need for the transformer to handle this duplication. What will 
happen at the moment is that we will receive twice every neighbor, and it is 
fine by us, because it is a quite small datasource, and 99.999% of the time it 
won't be changed.

It's fine for neighbor because vertex can be identified by id and there won't 
be duplication. 

But what about relationship, how do we model redundant links between two 
entities? There seems to be no id for relationships.

2. It should be 2 events. We want to make it as simple as possible, and in the 
same time as flexible as possible. So you should create 2 events and each one 
will have the neighbor connection.

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] [vitrage] how to 
useplaceholder vertex

Alexey,

I have to dig this old thread to clarify some issues I met during static 
datasource implementation. Hope that you can still recall the context :-)

I'll try to simplify this question with an example. The following configuration 
are snippet from static datasource

1. suppose we have three switches linked in a ring. What would be the expected 
entity events emit by the driver?

In my proposed driver, there will be three entities. And each relationship will 
appear both in source entity and target entity, e.g. s1->s2 will be included in 
both s1 and s2. Should the transformer handle this duplication or the graph 
utils will?
entities:
  - config_id: s1
    type: switch
    name: switch-1
    id: 12345
    state: available
  - config_id: s2
    type: switch
    name: switch-2
    id: 23456
    state: available
  - config_id: s3
    type: switch
    name: switch-3
    id: 34567
    state: available
relationships:
  - source: s1
    target: s2
    relation_type: linked
  - source: s2
    target: s3
    relation_type: linked
  - source: s3
    target: s1
    relation_type: linked
2. suppose we created a link between switch and nova.host. What will be the 
expected entity events? Should it be one entity event of s1 with h1 embedded as 
neighbor? Or two entity events, s1 and h1?
entities:
  - config_id: s1
    type: switch
    name: switch-1
    id: 12345
    state: available
  - config_id: h1
    type: nova.host
    id: 1
relationships:
  - source: s1
    target: h1
    relation_type: attached

On Wed, Dec 14, 2016 at 11:54 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
1. That is correct.

2. That is not quite correct.
In static we only define the main properties of each entity, meaning type, id, 
category and 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 Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex 
creation well.

So it looks like each resource type will have a primary datasource, e.g. 
nova.host for nova.host, nova.intance for nova.instance, that holds full 
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1] or 
not. At last, we agreed on a unified entity definition for both `nova.host` and 
`switch`, no extra key to indicate it is "external" (should create a 
placeholder).

If I understand it correctly, no placeholder will be created in this case. 
Because we can not distinguish them from the static configuration. And the 
properties of `nova.host` resource shall to be merged from `static` and 
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,
 
This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

Lets see.

1. There is no need for the transformer to handle this duplication. What will 
happen at the moment is that we will receive twice every neighbor, and it is 
fine by us, because it is a quite small datasource, and 99.999% of the time it 
won't be changed.

2. It should be 2 events. We want to make it as simple as possible, and in the 
same time as flexible as possible. So you should create 2 events and each one 
will have the neighbor connection.

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] [vitrage] how to 
useplaceholder vertex

Alexey,

I have to dig this old thread to clarify some issues I met during static 
datasource implementation. Hope that you can still recall the context :-)

I'll try to simplify this question with an example. The following configuration 
are snippet from static datasource

1. suppose we have three switches linked in a ring. What would be the expected 
entity events emit by the driver?

In my proposed driver, there will be three entities. And each relationship will 
appear both in source entity and target entity, e.g. s1->s2 will be included in 
both s1 and s2. Should the transformer handle this duplication or the graph 
utils will?
entities:
  - config_id: s1
type: switch
name: switch-1
id: 12345
state: available
  - config_id: s2
type: switch
name: switch-2
id: 23456
state: available
  - config_id: s3
type: switch
name: switch-3
id: 34567
state: available
relationships:
  - source: s1
target: s2
relation_type: linked
  - source: s2
target: s3
relation_type: linked
  - source: s3
target: s1
relation_type: linked
2. suppose we created a link between switch and nova.host. What will be the 
expected entity events? Should it be one entity event of s1 with h1 embedded as 
neighbor? Or two entity events, s1 and h1?
entities:
  - config_id: s1
type: switch
name: switch-1
id: 12345
state: available
  - config_id: h1
type: nova.host
id: 1
relationships:
  - source: s1
target: h1
relation_type: attached

On Wed, Dec 14, 2016 at 11:54 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
1. That is correct.

2. That is not quite correct.
In static we only define the main properties of each entity, meaning type, id, 
category and 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 Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex 
creation well.

So it looks like each resource type will have a primary datasource, e.g. 
nova.host for nova.host, nova.intance for nova.instance, that holds full 
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1] or 
not. At last, we agreed on a unified entity definition for both `nova.host` and 
`switch`, no extra key to indicate it is "external" (should create a 
placeholder).

If I understand it correctly, no placeholder will be created in this case. 
Because we can not distinguish them from the static configuration. And the 
properties of `nova.host` resource shall to be merged from `static` and 
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,
 
This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in which those events will arrive.
We have 2 use cases:
1.   Host1 event arrives before vm1.
In this case the processor will call the transformer of nova.host and will 
create a vertex for host1 in the graph with the full details of host1.
Then, vm1 event will arrive, the processor will create the vm1 vertex in the 
graph, it will update the host1 properties in the graph (because the host1 
details that are created in nova.instance are only its basic details such as: 
category, type, id, is_deleted, is_placeholder they host1 properties won’t be 
changed in the graph because those details are basic and can’t be changed), and 
then it will create an edge between vm1 and host1 (only the nova.instance knows 
to which nova.host it is connected and not vice versa).
2.   Vm1 e

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

[Weyl, Alexey (Nokia - IL)]

Bo problem Dong.

If you have any more questions, don’t be shy, just ask.

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, January 05, 2017 3:16 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: RE: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config




Hi Alexey,



Sorry, I saw the configuration. Need to click the 'raw' button in github to see 
the whole layout.yaml file.

Sorry to trouble you again and again.  :-)



BR,

dwj






原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：董文娟00101742;
抄送人：＜openstack-dev@lists.openstack.org＞
日 期 ：2017年01月04日 19:13
主 题 ：RE: Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config


We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions);
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



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





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

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

[Weyl, Alexey (Nokia - IL)]

We do write code in the zuul/layout.yaml:

  - name: openstack/puppet-vitrage

template:

  - name: merge-check

  - name: puppet-check-jobs

  - name: puppet-module-unit-jobs

  - name: puppet-beaker-jobs

  - name: puppet-beaker-jobs-xenial

  - name: puppet-branch-tarball-jobs

  - name: openstack-server-release-jobs

  - name: release-notes-jobs

  - name: openstack/python-vitrageclient
template:
  - name: merge-check
  - name: python-jobs
  - name: python35-jobs
  - name: check-requirements
  - name: publish-to-pypi
  - name: osc-plugin-jobs

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 10:59 AM
To: Weyl, Alexey (Nokia - IL)
Cc: openstack-dev@lists.openstack.org
Subject: 答复: Re: [openstack-dev] [ALU] [Vitrage] vitrage tempest job config

Hi Alexey,

As far as i know, every project needs to register in the zuul/layout.yaml[1], 
so zuul can submit the job to jenkins via gearman.
So the jenkins knows which jobs need to run and then run the job which defined 
in the jenkins/jobs/XXX.yaml.
Did i missing something? Or the job registeration moved from zuul/layout.yaml 
to jenkins/jobs/projects.yaml?
If yes, how can zuul know which jobs need to submit to jenkins?Thanks~

[1]https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml
 

BR,
dwj




原始邮件
发件人：Weyl,Alexey(Nokia-IL)
收件人：OpenStack Development Mailing List (not for usage questions);
日 期 ：2017年01月04日 16:30
主 题 ：Re: [openstack-dev] [ALU]   [Vitrage] vitrage tempest job config

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



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


__
OpenStack 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] [ALU] [Vitrage] vitrage tempest job config

[Weyl, Alexey (Nokia - IL)]

Hi Dong,

All of that data is configured the openstack-infra/project-config in github.

There you can find our changes by searching for vitrage.

The main files that we have pushed our changes are:
jenkins/jobs/vitrage.yaml
gerrit/projects.yaml
jenkins/jobs/projects.yaml

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Wednesday, January 04, 2017 9:49 AM
To: openstack-dev@lists.openstack.org
Subject: [ALU] [openstack-dev] [Vitrage] vitrage tempest job config


Hi all,
I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml.
Where does all the jobs configed?Thanks~
BR,
dwj



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

Re: [openstack-dev] [Vitrage] [aodh] Generig alarm help

[Weyl, Alexey (Nokia - IL)]

Thanks Julien (I thought that this may be the problem, but wasn't sure).

I have pushed some changes to gerrit for aodh and the client. If you could take 
a look and give some feedback that would be great :)

BR,
Alexey

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Wednesday, December 21, 2016 5:20 PM
> To: Weyl, Alexey (Nokia - IL)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Vitrage] [aodh] Generig alarm help
> 
> On Wed, Dec 21 2016, Weyl, Alexey (Nokia - IL) wrote:
> 
> > I encountered an error there in py27 which I don't quite understand
> > why it happens because I have changed all the correct places in the
> > client (maybe I need to have some appropriate code for this in the
> > aodh project itself as well?)
> 
> The client tests are ran against Aodh itself… and since you did not
> implement that in Aodh, well, it can't work.
> 
> So you need to move to the next step to have the tests working one day.
> :)
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Vitrage] [aodh] Generig alarm help

[Weyl, Alexey (Nokia - IL)]

Hi,

I have pushed the first code of the generic alarm to the aodhclient.

I encountered an error there in py27 which I don't quite understand why it 
happens because I have changed all the correct places in the client (maybe I 
need to have some appropriate code for this in the aodh project itself as well?)

The error is:
FAIL: 
aodhclient.tests.functional.test_alarm.AodhClientTest.test_generic_scenario
tags: worker-0
--
Empty attachments:
  pythonlogging:''
  stderr
  stdout

Traceback (most recent call last):
  File "aodhclient/tests/functional/test_alarm.py", line 436, in 
test_generic_scenario
'--project-id %s' % project_id))
  File "aodhclient/tests/functional/base.py", line 67, in aodh
return self.clients.aodh(*args, **kwargs)
  File "aodhclient/tests/functional/base.py", line 44, in aodh
merge_stderr, self.cli_dir)
  File 
"/home/jenkins/workspace/gate-python-aodhclient-python27-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/tempest/lib/cli/base.py",
 line 68, in execute
result_err)
tempest.lib.exceptions.CommandFailed: Command 
'['/home/jenkins/workspace/gate-python-aodhclient-python27-ubuntu-xenial/.tox/py27/bin/aodh',
 '--os-auth-plugin', 'aodh-noauth', '--user-id', 
'3862e83e-a752-42fa-8a4f-a66bdd23c503', '--project-id', 
'b4cdce18-f33e-4d6a-9d4f-9e6d4c4437bb', '--aodh-endpoint', 
'http://localhost:8042', 'alarm', 'create', '--type', 'generic', '--name', 
'gen_alarm_1', '--project-id', 'd2243574-8472-46b0-a63b-70f6bba6fd99']' 
returned non-zero exit status 1.
stdout:

stderr:
Unknown attribute for argument data: generic_rule (HTTP 400) (Request-ID: 
req-2e5db4a4-a07b-40fa-92a8-c3eeae6155e4)

You can find it here:
https://review.openstack.org/#/c/413008/

Can any please take a look at it, and knows why it happens?

Thanks in advance,
Alexey


__
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] [ALU] Re: [ALU] [vitrage] how to use placeholder vertex

[Weyl, Alexey (Nokia - IL)]

1. That is correct.

2. That is not quite correct.
In static we only define the main properties of each entity, meaning type, id, 
category and 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 Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex 
creation well.

So it looks like each resource type will have a primary datasource, e.g. 
nova.host for nova.host, nova.intance for nova.instance, that holds full 
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1] or 
not. At last, we agreed on a unified entity definition for both `nova.host` and 
`switch`, no extra key to indicate it is "external" (should create a 
placeholder).

If I understand it correctly, no placeholder will be created in this case. 
Because we can not distinguish them from the static configuration. And the 
properties of `nova.host` resource shall to be merged from `static` and 
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,
 
This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in which those events will arrive.
We have 2 use cases:
1.   Host1 event arrives before vm1.
In this case the processor will call the transformer of nova.host and will 
create a vertex for host1 in the graph with the full details of host1.
Then, vm1 event will arrive, the processor will create the vm1 vertex in the 
graph, it will update the host1 properties in the graph (because the host1 
details that are created in nova.instance are only its basic details such as: 
category, type, id, is_deleted, is_placeholder they host1 properties won’t be 
changed in the graph because those details are basic and can’t be changed), and 
then it will create an edge between vm1 and host1 (only the nova.instance knows 
to which nova.host it is connected and not vice versa).
2.   Vm1 event arrives before host1.
In this case the processor will add vm1 to the graph, then it will add the 
host1 placeholder to the graph (so we will know to which host vm1 is connected) 
and then add the edge between them.
Then when the processor will handle with the host1 event, it will just add some 
properties of the host1 vertex, and of course will change the is_placeholder 
property of host1 to false.
We also has the consistency service that runs every 10 minutes (its 
configurable with the snapshot_interval) and checks if there are vertices that 
are is_placeholder=True and are in the graph more then 2*snapshot_interval time 
then it means that such a vertex of host1 for example doesn’t really exists and 
it deletes it from the graph). 
In addition, when we understand that we need to delete some entity from the 
graph, upon delete notification for example, then we don’t delete it right 
away, we change the is_deleted property of that entity to True, and we will 
delete it on the next run of the consistency service. The reason we do that, is 
because we need it for the evaluator, because it runs a subgraph matching 
algorithm on the graph, and if the entity that is supposed to be there doesn’t 
appear then it won’t work correctly.
 
The best way to create 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, December 14, 2016 10:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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 deal with it?
 
Similar question for how to create a vertex when there is already a placeholder 
with same ID
 
[1]: 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
 
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lis

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in which those events will arrive.
We have 2 use cases:

1.   Host1 event arrives before vm1.

In this case the processor will call the transformer of nova.host and will 
create a vertex for host1 in the graph with the full details of host1.

Then, vm1 event will arrive, the processor will create the vm1 vertex in the 
graph, it will update the host1 properties in the graph (because the host1 
details that are created in nova.instance are only its basic details such as: 
category, type, id, is_deleted, is_placeholder they host1 properties won’t be 
changed in the graph because those details are basic and can’t be changed), and 
then it will create an edge between vm1 and host1 (only the nova.instance knows 
to which nova.host it is connected and not vice versa).

2.   Vm1 event arrives before host1.

In this case the processor will add vm1 to the graph, then it will add the 
host1 placeholder to the graph (so we will know to which host vm1 is connected) 
and then add the edge between them.

Then when the processor will handle with the host1 event, it will just add some 
properties of the host1 vertex, and of course will change the is_placeholder 
property of host1 to false.

We also has the consistency service that runs every 10 minutes (its 
configurable with the snapshot_interval) and checks if there are vertices that 
are is_placeholder=True and are in the graph more then 2*snapshot_interval time 
then it means that such a vertex of host1 for example doesn’t really exists and 
it deletes it from the graph).

In addition, when we understand that we need to delete some entity from the 
graph, upon delete notification for example, then we don’t delete it right 
away, we change the is_deleted property of that entity to True, and we will 
delete it on the next run of the consistency service. The reason we do that, is 
because we need it for the evaluator, because it runs a subgraph matching 
algorithm on the graph, and if the entity that is supposed to be there doesn’t 
appear then it won’t work correctly.

The best way to create 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, December 14, 2016 10:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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 deal with it?

Similar question for how to create a vertex when there is already a placeholder 
with same ID

[1]: 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
--
Yujun
__
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] [Aodh] Vitrage – Aodh Integration

[Weyl, Alexey (Nokia - IL)]

Hi Julien,

Thank you for your response.

> > We are starting to work on the following BP proposal:
> > https://review.openstack.org/#/c/408060/
> >
> > In this regard, I have two questions:
> > 1. What should this new alarm be called?
> 
> Ah naming things, the biggest problem in CS. Well I'd pick "manual" as
> a name to indicate that nothing is done by Aodh evaluator. Thoughts?

>From Vitrages' point of view "manual" the action is not manual because it is 
>all done automatically.
How about "generic"? "custom"? "external"?

> > 2. As I'm new in Aodh, do you have any pointers or suggestions about
> where to start?
> 
> Not really, though deploying it and using it is probably a good start.
> The spec you started is a good idea to lay out your thoughts and will
> help us understand and point any issue we may have missed.

I have already used ceilometer and aodh in the past. 
I am trying to understand where exactly in Aodh code the new alarm should be 
because it is not part of the evaluator (as other alarms are).

I am waiting for your thoughts on the spec.

Thanks,
Alexey Weyl

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Thursday, December 08, 2016 2:27 PM
> To: Weyl, Alexey (Nokia - IL)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Vitrage] [Aodh] Vitrage – Aodh
> Integration
> 
> On Wed, Dec 07 2016, Weyl, Alexey (Nokia - IL) wrote:
> 
> Hi Alexey,
> 
> > We are starting to work on the following BP proposal:
> > https://review.openstack.org/#/c/408060/
> >
> > In this regard, I have two questions:
> > 1. What should this new alarm be called?
> 
> Ah naming things, the biggest problem in CS. Well I'd pick "manual" as
> a name to indicate that nothing is done by Aodh evaluator. Thoughts?
> 
> > 2. As I'm new in Aodh, do you have any pointers or suggestions about
> where to start?
> 
> Not really, though deploying it and using it is probably a good start.
> The spec you started is a good idea to lay out your thoughts and will
> help us understand and point any issue we may have missed.
> 
> I'll review your spec ASAP.
> 
> Cheers,
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */

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

[openstack-dev] [Vitrage] [Aodh] Vitrage – Aodh Integration

[Weyl, Alexey (Nokia - IL)]

Hi all,

My name is Alexey Weyl and I am a core contributor in the Vitrage team.

In the Austin Openstack summit we discussed with the Aodh team about creating a 
new alarm type, and after explaining it we got an approval [1].

Members from the Aodh team were in our design session in the Openstack summit 
in Barcelona, where we had further discussed this issue.

Vitrage is building a graph from all the datasources that it has (nova, heat, 
aodh, zabbix, neutron, physical entities, and more) and then when some states 
or alarms in Vitrage are changed then it may raise some new alarm or change 
some other properties of the entity in the graph.

Vitrage then pushes the raised alarms to Aodh in order that all of the projects 
will be aware of the alarm that has occurred.

We are starting to work on the following BP proposal: 
https://review.openstack.org/#/c/408060/

In this regard, I have two questions:
1. What should this new alarm be called?
2. As I'm new in Aodh, do you have any pointers or suggestions about where to 
start?


Thanks in Advance,
Alexey

[1] https://etherpad.openstack.org/p/newton-telemetry-vitrage In addition

__
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] [ALU] Re: [ALU] Re: [ALU] [vitrage] datasource driverreturnsentities only?

[Weyl, Alexey (Nokia - IL)]

Hi,

Yes, the entity_type is datasource_type, and the entity_id is the resources’ id 
which came from it’s datasource.

The example is correct, and just for the clarification, the “12345678” is the 
id of that entity in the datasource.

Another clarification that I want to make sure, is that the static datasource 
(and actually each datasource), retrieves the transformer of the neighbor from 
the transformers dictionary that each transformer holds, and using the 
neighbors’ transformer it creates the placeholder of the neighbor (this is 
because each 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)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] datasource 
driverreturnsentities only?

Thanks for clarification.

Is `entity_type` equivalent to datasource type? And `entity_id` should be 
interpreted by the related datasource, is that right.

For example, "RESOURCE:nova.host:12345678" is from `nova.host` datasource and 
`12345678` is how `nova.host` identify a resource.

--
Yujun

On Sun, Dec 4, 2016 at 4:35 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi Yujun,

I see the confusion.

The way we find the resource entity (it’s different than finding the alarm 
entity, but it’s ok because the static datasource is defining relationships 
between resource entities) is in the following way:
Each entity has a vitrage_id which is defined by 
“RESOURCE:: (we are planning in the very near future to 
change the vitrage_id to be a UUID, but at the moment your change doesn’t need 
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<mailto:zhangyujun%2b...@gmail.com>]
Sent: Thursday, December 01, 2016 4:16 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver 
returnsentities only?

Another question, how do we describe an entity from another datasource in 
static datasource config?

In the test resources of static_physical datasource, it seems to be referred as 
following. Does it means that it will be `nova.host` to find the matched 
resource? If so, how will `nova.host` identify the resource, by name or by id?

relationships:
  - type: nova.host
name: host-2
id: 2
relation_type: attached

On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits 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,
Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

I see the confusion.

The way we find the resource entity (it’s different than finding the alarm 
entity, but it’s ok because the static datasource is defining relationships 
between resource entities) is in the following way:
Each entity has a vitrage_id which is defined by 
“RESOURCE:: (we are planning in the very near future to 
change the vitrage_id to be a UUID, but at the moment your change doesn’t need 
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]
Sent: Thursday, December 01, 2016 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver 
returnsentities only?

Another question, how do we describe an entity from another datasource in 
static datasource config?

In the test resources of static_physical datasource, it seems to be referred as 
following. Does it means that it will be `nova.host` to find the matched 
resource? If so, how will `nova.host` identify the resource, by name or by id?

relationships:
  - type: nova.host
name: host-2
id: 2
relation_type: attached

On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits 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,
Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits 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,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
Yujun
__
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] Suspected SPAM - Re: Suspected SPAM - [vitrage] datasources terminology

[Weyl, Alexey (Nokia - IL)]

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)
Subject: Suspected SPAM - Re: [openstack-dev] Suspected SPAM - [vitrage] 
datasources terminology

Hi,

A new suggestion:

• event_type: the type of event/notification that comes from the datasource. 
For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
• graph_action: used to tell the evaluator what to do with the entity - create, 
update or delete it.
• datasource_action: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

What do you think?
Ifat.


From: "Afek, Ifat (Nokia - IL)"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 29 November 2016 at 09:26
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Suspected SPAM - [openstack-dev] [vitrage] datasources terminology

Hi,

I think we have a confusing terminology in Vitrage datasources. 

The following parameters are used in the drivers and transformers: 
• event_type: the type of event/notification that comes from the datasource. 
For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
• event_action: used to tell the evaluator what to do with the entity - create, 
update or delete it.
• action_type: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

Personally I find these names very confusing. 
My suggestion is to rename action_type to datasource_mode, or something similar.

Your thoughts?

Thanks,
Ifat.

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

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

[Weyl, Alexey (Nokia - IL)]

Sounds good to me ☺

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Monday, November 28, 2016 10:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [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_utils.py` to `utils`?

--
Yujun
__
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] [ALU] Re: [vitrage] about aodh alarm notification

[Weyl, Alexey (Nokia - IL)]

I also thought that my second proposal is the more reasonable one, calling the 
get_all in the AodhDriver contructor.

Looking forward to see the updated code, and push it upstream ☺

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Monday, November 28, 2016 8:10 AM
To: dong.wenj...@zte.com.cn
Cc: OpenStack Development Mailing List (not for usage questions); Hefetz, Idan 
(Nokia - IL); zhang.yuj...@zte.com.cn
Subject: [ALU] 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 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>> 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 Zhang <zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>>

2016-11-28 11:23

收件人

"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, 
"dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>" 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>>

抄送

"Hefetz, Idan (Nokia - IL)" 
<idan.hef...@nokia.com<mailto:idan.hef...@nokia.com>>, 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>" 
<zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>>

主题

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<mailto: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 notifications.

I think it might not be easily accepted since sending only the changes on 
update notification looks more reasonable to me.
2.   We can add a cache in the aodh driver, and call the get_all method in 
the AodhDriver constructor or when the first notification happens and fill the 
cache with the data. Then for each notification that arrives you  will update 
that cache in the aodh notification service, and send then event with all the 
data you need.

I doubt this will degrade the performance for the first notification since 
there will be additional conversation to retrieve the full data.

My proposal is to share a cache between snapshot service and listener service 
and I think it is a common requirements for all datasource using PUSH method.
__
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] about aodh alarm notification

[Weyl, Alexey (Nokia - IL)]

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

2.   We can add a cache in the aodh driver, and call the get_all method in 
the AodhDriver constructor or when the first notification happens and fill the 
cache with the data. Then for each notification that arrives you  will update 
that cache in the aodh notification service, and send then event with all the 
data you need.

BR,
Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Friday, November 25, 2016 2:28 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; zhang.yuj...@zte.com.cn
Subject: 答复: RE: RE: [openstack-dev] [vitrage] about aodh alarm notification


EmThe solution goes back to my first question.
Snapshot service calls get_all, and caches all the alarms.
But listener service can't get the cache because there are two services and 
can't share the cache.


BR,
dwj





"Weyl, Alexey (Nokia - IL)" 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>>

2016-11-24 23:50

收件人

"dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>" 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>>

抄送

"Hefetz, Idan (Nokia - IL)" 
<idan.hef...@nokia.com<mailto:idan.hef...@nokia.com>>, "Afek, Ifat (Nokia - 
IL)" <ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>>, 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>" 
<zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>>

主题

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







It seems that you will need to have a cache for that issue.
Due to the fact that AODH alarms aren’t deleted, and stay alive (in AODH) when 
their state is changed to ok (but in this case aren’t supposed to appear in 
Vitrage), and then when the state is changed back to error (‘alarm’) they are 
supposed to appear in Vitrage with all the data, the most simple way to do that 
(without touching the core processor and architecture) is by saving those 
alarms of AODH in cache in the AODH driver, update its data every change that 
arrive to the driver, and then when a notification arrives and if the state 
that arrived is different than OK and the state that was in the cache is OK 
then send an event with all the data updated in the cache to the queue, 
otherwise send only the data received from the oslo bus to the queue (don’t 
forget of course to update the cache each time an event received, and each time 
we call the get_all of aodh (every snapshot_interval time) we can update the 
data in the cache as well.

Alexey

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 11:24 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>; 
zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>
Subject: 答复: RE: [openstack-dev] [vitrage] about aodh alarm notification


Hi Weyl Alexey,

Another question:
If we received the alarm.creation notification with the 'ok' state, we filter 
it and don't create vertex in the Graph.
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex.
How can I handle this? Thanks~


BR,
dwj



"Weyl, Alexey (Nokia - IL)" 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>>

2016-11-24 16:25


收件人

"dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>" 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>>, "Afek, Ifat (Nokia - 
IL)" <ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>>, "Hefetz, Idan (Nokia - 
IL)" <idan.hef...@nokia.com<mailto:idan.hef...@nokia.com>>, 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>" 
<zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>>

抄送

"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

主题

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











Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.r

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

[Weyl, Alexey (Nokia - IL)]

It seems that you will need to have a cache for that issue.
Due to the fact that AODH alarms aren’t deleted, and stay alive (in AODH) when 
their state is changed to ok (but in this case aren’t supposed to appear in 
Vitrage), and then when the state is changed back to error (‘alarm’) they are 
supposed to appear in Vitrage with all the data, the most simple way to do that 
(without touching the core processor and architecture) is by saving those 
alarms of AODH in cache in the AODH driver, update its data every change that 
arrive to the driver, and then when a notification arrives and if the state 
that arrived is different than OK and the state that was in the cache is OK 
then send an event with all the data updated in the cache to the queue, 
otherwise send only the data received from the oslo bus to the queue (don’t 
forget of course to update the cache each time an event received, and each time 
we call the get_all of aodh (every snapshot_interval time) we can update the 
data in the cache as well.

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 11:24 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; zhang.yuj...@zte.com.cn
Subject: 答复: RE: [openstack-dev] [vitrage] about aodh alarm notification


Hi Weyl Alexey,

Another question:
If we received the alarm.creation notification with the 'ok' state, we filter 
it and don't create vertex in the Graph.
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex.
How can I handle this? Thanks~


BR,
dwj





"Weyl, Alexey (Nokia - IL)" 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>>

2016-11-24 16:25

收件人

"dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>" 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>>, "Afek, Ifat (Nokia - 
IL)" <ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>>, "Hefetz, Idan (Nokia - 
IL)" <idan.hef...@nokia.com<mailto:idan.hef...@nokia.com>>, 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>" 
<zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>>

抄送

"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

主题

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







Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to update 
the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh uuid so 
you know the vitrage_id, and you can pass only the properties that you have 
received and want to update (and not all the properties that there in the aodh 
vertex). All the other properties that you haven't received that haven't 
changed you can pass them as None and they won't be changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan (Nokia - 
IL); zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>
Cc: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages,

Currently there are four aodh alarm notifications we need to handle:
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion'

Only the alarm.creation notification carries the alarm detail info.
So we need to cache the alarm info.
When we receive other notifications, we can fill all fields from the cache.

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification.
So we need to get_all when vitrage services startup.
As `SnapshotsService` will get all alarms info when it startup.
But `SnapshotsService` and `ListenerService` are two services,
they can't share the cache data unless they communicate with each other.
This wil be a big change.

Are there any other better solutions? I need some help, thanks :)

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

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

[Weyl, Alexey (Nokia - IL)]

Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to update 
the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh uuid so 
you know the vitrage_id, and you can pass only the properties that you have 
received and want to update (and not all the properties that there in the aodh 
vertex). All the other properties that you haven't received that haven't 
changed you can pass them as None and they won't be changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan (Nokia - 
IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages, 

Currently there are four aodh alarm notifications we need to handle: 
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion' 

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info. 
When we receive other notifications, we can fill all fields from the cache. 

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification. 
So we need to get_all when vitrage services startup. 
As `SnapshotsService` will get all alarms info when it startup. 
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other. 
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :) 

BR, 
dwj

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

Re: [openstack-dev] [Vitrage] Problem at our gate in gerrit

[Weyl, Alexey (Nokia - IL)]

Hi,

We have temporary set the heat datasource tempest to ignore because of some 
problems with the heatclient that we didn't succeed to resolve in the xenial 
image.

I have rechecked all the failed commits.

If someone wants and have the time to check how exactly we should use the 
heatclient in xenial, that can be great.
Otherwise we will fix it soon.

Best regards,
Alexey

> -Original Message-
> From: vin...@vn.fujitsu.com [mailto:vin...@vn.fujitsu.com]
> Sent: Tuesday, November 22, 2016 11:43 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Vitrage] Problem at our gate in gerrit
> 
> Thank you for your work!
> 
> Best regards,
> 
> Vinh Nguyen Trong
> PODC - Fujitsu Vietnam Ltd.
> Mobile: +84-164-953-8507 - Email: vin...@vn.fujitsu.com
> 
> > -----Original Message-
> > From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> > Sent: Tuesday, November 22, 2016 4:34 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: [openstack-dev] [Vitrage] Problem at our gate in gerrit
> >
> > Hi,
> >
> > We have some problems at our gate in gerrit.
> >
> > We have fixed one problem by changing the image that the tempests run
> > on to xenial image.
> >
> > But that has created some other problem, and we are checking it.
> >
> > I will send an email to update when the problem is resolved.
> >
> > Alexey
> >
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Vitrage] Problem at our gate in gerrit

[Weyl, Alexey (Nokia - IL)]

Hi,

We have some problems at our gate in gerrit. 

We have fixed one problem by changing the image that the tempests run on to 
xenial image.

But that has created some other problem, and we are checking it.

I will send an email to update when the problem is resolved.

Alexey

__
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] [ALU] Re: [ALU] [vitrage]bp:static-datasource-config-formatworking items

[Weyl, Alexey (Nokia - IL)]

Ok, sounds good.

We need to understand what is the common way in openstack to work with 
deprecated code.

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, November 15, 2016 12:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] 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 test and keep backward compatibility.

Detail replies inline.

On Tue, Nov 15, 2016 at 5:51 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com> wrote:
Hi Yujun,

Good job! This is a very important change for Vitrage.

I have a couple of questions please:
1. Why do we want to create a new datasource ‘static’ and not rename the 
current ‘static_physical’ datasource and change it to work with the new format?
I don't want to break it during the evolution.
2. How are you planning to use the old 'static_physical' datasource  as a proxy 
if you said that you want to remove it?
Good point. Any suggestion on how we hide the deprecated modules? Move it as a 
submodule in new module.
3. What kind of merge is needed in the evaluator?
Parsing of `definition` section would be a common module for both evaluator and 
static data source 
4. I saw the implementation of the driver.py in static, and it doesn't do 
anything at the moment? (if you are still working on one of the patches then 
please market it as -1 in the code-review that we will know that you are still 
working on it.
Yes, skeleton is skeleton. Since I'm working remotely with vitrage team. I want 
to keep you updated on the progress. Still, it is complete with unit test and 
backward compatibility and will reduce further review work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

Good job! This is a very important change for Vitrage.

I have a couple of questions please:
1. Why do we want to create a new datasource ‘static’ and not rename the 
current ‘static_physical’ datasource and change it to work with the new format?
2. How are you planning to use the old 'static_physical' datasource  as a proxy 
if you said that you want to remove it?
3. What kind of merge is needed in the evaluator?
4. I saw the implementation of the driver.py in static, and it doesn't do 
anything at the moment? (if you are still working on one of the patches then 
please market it as -1 in the code-review that we will know that you are still 
working on it.)

BR,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, November 15, 2016 9:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] 
bp:static-datasource-config-formatworking 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_physical` module
3. remove `static_physical` datasource and print deprecation warning in `static`
4. merge common logic with scenario template evaluator
Requesting for comments.

P.S. I chose the name `static` since it is actually not limited to physical 
entities. Virtual entities can also be described in `static` file if there is 
no dynamic source.

[1]: 
https://blueprints.launchpad.net/vitrage/+spec/static-datasource-config-format

--
Yujun
__
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] Installation

[Weyl, Alexey (Nokia - IL)]

Yes, this is how zabbix notifies on each new trigger or changes on existing 
triggers to Vitrage.

From: lương hữu tuấn [mailto:tuantulu...@gmail.com]
Sent: Wednesday, October 05, 2016 7:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Alexey,

Yeap, it is what i mean. It seems that the connection channel between Zabbix 
and Vitrage just only through this script.

Btw, thanks a lot

Br,

Tuan

On Wed, Oct 5, 2016 at 3:37 PM, Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi,

When you say notification in Zabbix, do you mean a new trigger in Zabbix?

If yes, then if you have configured the auxiliary Zabbix script successfully 
then the script should recognize any trigger raised in zabbix and send the 
trigger notification on the oslo bus.

Best Regards,
Alexey

From: lương hữu tuấn 
[mailto:tuantulu...@gmail.com<mailto:tuantulu...@gmail.com>]
Sent: Wednesday, October 05, 2016 4:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi,

I have another question based on the getting information of vitrage from 
monitoring solution. As i see that we have the default one now is nagios and 
with the zabbix, we just have only the script that gets information from zabbix 
as below:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py

If yes as above, so all the things like structure of zabbix notification, what 
if i create a new notification in zabbix, can vitrage understand it?

Br,

Tutj

On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com<mailto:paul.vad...@enea.com>

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com<http://www.enea.com/>

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


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


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

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

Re: [openstack-dev] [Vitrage] Installation

[Weyl, Alexey (Nokia - IL)]

Hi,

When you say notification in Zabbix, do you mean a new trigger in Zabbix?

If yes, then if you have configured the auxiliary Zabbix script successfully 
then the script should recognize any trigger raised in zabbix and send the 
trigger notification on the oslo bus.

Best Regards,
Alexey

From: lương hữu tuấn [mailto:tuantulu...@gmail.com]
Sent: Wednesday, October 05, 2016 4:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi,

I have another question based on the getting information of vitrage from 
monitoring solution. As i see that we have the default one now is nagios and 
with the zabbix, we just have only the script that gets information from zabbix 
as below:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py

If yes as above, so all the things like structure of zabbix notification, what 
if i create a new notification in zabbix, can vitrage understand it?

Br,

Tutj

On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) 
> wrote:
Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


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

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

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

I don’t think we have a support for different versions of openstack at the same 
time at the moment.

We have thought of such a requirement yet, but I think it can be done.

If you can, please add a blueprint with all the details for such a feature.

In addition, we now have a documentation 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
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 connect multiple openstack data sources, furthermore, 
different version of openstack (liberty, newton), at the same time?

To monitor existing systems, this might be a common requirement.
On Thu, Sep 1, 2016 at 5:16 PM Yujun Zhang 
> wrote:
Thanks for explanation. I'll give it a try.

Answer to BTW, it is Liberty on Ubuntu 14.04 deployed by Fuel 8.0.
--
Yujun

On Wed, Aug 31, 2016 at 2:42 PM Afek, Ifat (Nokia - IL) 
> wrote:
Hi Yujun,

Using Vitrage for an external openstack environment should be possible, but it 
has never been tested.

There are some issues to consider:

  *   You should set the ip of the keystone in vitrage.conf, and make sure you 
can access it
  *   You will need to install, together with Vitrage, many dependent openstack 
libraries
  *   In order to access Vitrage API, you will either need to install keystone 
on Vitrage environment, or to configure an endpoint for 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.

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

Re: [openstack-dev] 答复: Re: 答复: [vitrage] can't get nagios datasource

[Weyl, Alexey (Nokia - IL)]

Hi Dong,

When you install from scratch it comes with nagios in the types property.

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Monday, September 05, 2016 8:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] 答复: Re: 答复: [vitrage] can't get nagios datasource


Hi Alexey,

There is a old vitrage.conf in my env, I didn't config Nagios in the 
datasources section.
Is it can't be overwrited when i redeploy a new  OS env?

BR,
dwj





"Weyl, Alexey (Nokia - IL)" 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>>

2016-09-05 15:24
请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>


收件人

"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

抄送

主题

Re: [openstack-dev] 答复:   [vitrage] can't get nagios datasource







Hi Dong,

What was the problem?

Alexey

From: dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn> 
[mailto:dong.wenj...@zte.com.cn]
Sent: Monday, September 05, 2016 8:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] 答复: [vitrage] can't get nagios datasource


I already found the problem, thanks~

dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>

2016-09-05 12:41


请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>



收件人

"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

抄送

主题

[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 
`conf.datasources.types` as follows:
It seems that the oslo_config can't get the Nagios opts.
I checked all the Nagios config and didn't find the error.
Is there any change about the config?

2016-09-05 14:48:55.680 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.host
2016-09-05 14:48:55.680 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.instance
2016-09-05 14:48:55.681 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.zone
2016-09-05 14:48:55.681 1288 INFO vitrage.service [-] 
-dwj-prepare_service: static_physical
2016-09-05 14:48:55.682 1288 INFO vitrage.service [-] 
-dwj-prepare_service: aodh
2016-09-05 14:48:55.682 1288 INFO vitrage.service [-] 
-dwj-prepare_service: cinder.volume
2016-09-05 14:48:55.683 1288 INFO vitrage.service [-] 
-dwj-prepare_service: neutron.network
2016-09-05 14:48:55.683 1288 INFO vitrage.service [-] 
-dwj-prepare_service: neutron.port
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [vitrage] can't get nagios datasource

[Weyl, Alexey (Nokia - IL)]

Hi Dong,

What was the problem?

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Monday, September 05, 2016 8:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] 答复: [vitrage] can't get nagios datasource


I already found the problem, thanks~



dong.wenj...@zte.com.cn

2016-09-05 12:41
请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 
>


收件人

"OpenStack Development Mailing List (not for usage questions)" 
>

抄送

主题

[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 
`conf.datasources.types` as follows:
It seems that the oslo_config can't get the Nagios opts.
I checked all the Nagios config and didn't find the error.
Is there any change about the config?

2016-09-05 14:48:55.680 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.host
2016-09-05 14:48:55.680 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.instance
2016-09-05 14:48:55.681 1288 INFO vitrage.service [-] 
-dwj-prepare_service: nova.zone
2016-09-05 14:48:55.681 1288 INFO vitrage.service [-] 
-dwj-prepare_service: static_physical
2016-09-05 14:48:55.682 1288 INFO vitrage.service [-] 
-dwj-prepare_service: aodh
2016-09-05 14:48:55.682 1288 INFO vitrage.service [-] 
-dwj-prepare_service: cinder.volume
2016-09-05 14:48:55.683 1288 INFO vitrage.service [-] 
-dwj-prepare_service: neutron.network
2016-09-05 14:48:55.683 1288 INFO vitrage.service [-] 
-dwj-prepare_service: neutron.port
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

In order for the static_physical to work for different datasources without the 
restrictions, you need to do the following changes:
Go to the static_physical transformer:

1.   Remove the methods: _register_relations_direction, 
_find_relation_direction_source.

2.   Add to the static_physical.yaml for each definition also a field for 
direction which will indicate the source and the destination between the 
datasources.

3.   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, 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...It seems the datasource just construct the entities and send 
them over event bus to entity graph processor. I need to dig further to find 
out the exact point the "backup" relationship is filtered.

I think we should some how keep the validation of relationship type. It is so 
easy to make typo when creating the template manually (I did this quite 
often...).

My idea is to delegate the validation to datasource instead of enumerating all 
constants it in evaluator. I think this will introduce better extensibility. 
Any comments?

On Thu, Aug 25, 2016 at 1:32 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto: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.

Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@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

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) 
<ifat.a...@nokia.com<mailto:ifat.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: Yujun Zhang
Date: Monday, 22 August 2016 at 08:37
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 limited to it?

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

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.

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

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) 
> 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: Yujun Zhang
Date: Monday, 22 August 2016 at 08:37
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 limited to it?

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

It seems to be due to changes that were made in other projects.

We have the same problems with our commits.

We are waiting to tomorrow to see it there will be any fixes in those projects 
for those problems.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Friday, 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 according to the console log [2].

Does anybody encountering the same issue as me?

```
2016-08-18 
19:59:15.155472
 | 2016-08-18 19:59:15.155 | ++ 
/opt/stack/new/vitrage/devstack/post_test_hook.sh:source:L31: sudo 
oslo-config-generator --config-file etc/config-generator.tempest.conf 
--output-file etc/tempest.conf
2016-08-18 
19:59:15.402397
 | 2016-08-18 19:59:15.401 | Traceback (most recent call last):2016-08-18 
19:59:15.403804
 | 2016-08-18 19:59:15.403 | File "/usr/local/bin/oslo-config-generator", line 
11, in 
2016-08-18 
19:59:15.405044
 | 2016-08-18 19:59:15.404 | sys.exit(main())
2016-08-18 
19:59:15.406367
 | 2016-08-18 19:59:15.406 | File 
"/usr/local/lib/python2.7/dist-packages/oslo_config/generator.py", line 478, in 
main
2016-08-18 
19:59:15.407918
 | 2016-08-18 19:59:15.407 | conf(args, version=version)
2016-08-18 
19:59:15.409207
 | 2016-08-18 19:59:15.408 | File 
"/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2256, in 
__call__
2016-08-18 
19:59:15.410630
 | 2016-08-18 19:59:15.410 | raise 
ConfigFilesNotFoundError(self._namespace._files_not_found)
2016-08-18 
19:59:15.412069
 | 2016-08-18 19:59:15.411 | oslo_config.cfg.ConfigFilesNotFoundError: Failed 
to find some config files: 
/opt/stack/new/tempest/etc/config-generator.tempest.conf
```


[1] https://review.openstack.org/#/c/357001/
[2] 
http://logs.openstack.org/01/357001/1/check/gate-vitrage-dsvm-api/2e679a2/console.html

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

Re: [openstack-dev] [nova] [vitrage] Nova host list api - performance

[Weyl, Alexey (Nokia - IL)]

I need to check if the data transferred is compressed, but in either way I 
don’t want to get more than 99% (that the manager object takes) of the data 
sent for the instance / host / availablility zone, so I would like to get the 
data without that property.

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Monday, August 08, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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<mailto:alexey.w...@nokia.com>> wrote:
Hi,

I am running the "client.hosts.list()" command in Vitrage to get all the hosts 
in the system (we also run similar commands for availability zones and 
instances). Vitrage does this to gain a holistic view of system resources[1].

As part of our performance checks we noticed that when calling 
client.hosts.list(), the info on each host includes the "HostManager" object, 
which weighs about 840KB on the oslo messaging bus, which is quite heavy.

We would like to reduce that amount of data transferred, to improve 
performance. Is it possible to pass some parameter in "client.hosts.list()" so 
the manager property won't be sent on the bus?

Thanks in advance,
Alexey

[1] https://wiki.openstack.org/wiki/Vitrage


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

[openstack-dev] [nova] [vitrage] Nova host list api - performance

[Weyl, Alexey (Nokia - IL)]

Hi,

I am running the "client.hosts.list()" command in Vitrage to get all the hosts 
in the system (we also run similar commands for availability zones and 
instances). Vitrage does this to gain a holistic view of system resources[1]. 

As part of our performance checks we noticed that when calling 
client.hosts.list(), the info on each host includes the "HostManager" object, 
which weighs about 840KB on the oslo messaging bus, which is quite heavy.

We would like to reduce that amount of data transferred, to improve 
performance. Is it possible to pass some parameter in "client.hosts.list()" so 
the manager property won't be sent on the bus?

Thanks in advance,
Alexey

[1] https://wiki.openstack.org/wiki/Vitrage


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

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

[Weyl, Alexey (Nokia - IL)]

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 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] Normalized Resource State

[Weyl, Alexey (Nokia - IL)]

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 Message-
> From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> Sent: Monday, May 16, 2016 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]
> > 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 values : TERMINATED,
> > ERROR, UNRECOGNIZED ,  SUSPENDED ,   RESCUED ,  RESIZED ,  TRANSIENT
> ,
> >  SUBOPTIMAL,  RUNNING ,  UNDEFINED.
> >
> > I think that 2 states are missing :
> > 1. IN_MAINTENANCE - which represent that this resource is under
> > maintenance 2. TERMINATING - which represent transient state that
> > terminating the resource.
> 
> MAINTENANCE state is relevant also for OPNFV Doctor workflow (which is
> currently in discussion), so I think we should add it. We can add
> TERMINATING as well.
> 
> >
> > And regards RUNNING state maybe ACTIVE is more appropriate. Horizon
> > also show active state for instance, networks and ports.
> 
> Fine with me to replace RUNNING with ACTIVE.
> 
> >
> > What do you think ?
> >
> > Eylon Malin
> 
> Ifat.
> 
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi Tim,

Sounds good. I’ll take a look at the links you sent below and will let you know 
if I have any questions.

Thanks,
Alexey

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, May 12, 2016 9:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

Hi Alexey,

That sounds like a good use case.  If I understand it correctly, the use case 
can be accomplished by doing two things:

1. Writing a Vitrage datasource driver that whenever it receives an alarm, 
pulls Vitrage's API.  I'd recommend having the datasource driver pulling 
periodically, and a push simply requests an immediate refresh of that data.  
That way, the data is available as soon as you create the datasource driver.

That would mean your datasource driver inherits from both the 
PushedDataSourceDriver and PollingDataSourceDriver classes.   Pulling data has 
been in Congress since day 1, and all but one of our drivers pull data, so 
there are plenty of examples in congress/datasources.   Push is new 
functionality that Masahito added in Mitaka.

Here are the docs on writing a datasource driver.  I'd start with pulling the 
data from Vitrage and adding the push functionality once that is working (using 
the request_refresh() method from the PushedDataSourceDriver base class to 
force the poller to immediately pull the data).

http://docs.openstack.org/developer/congress/cloudservices.html

2. Writing a policy that uses the information about the host alarm that the 
datasource driver pulled.  Below are 2 examples, where I'm assuming that the 
vitrage datasource driver creates a table called host_alarm within Congress.

- reactive policy like "whenever the host alarm is ON, pause all the VMs on 
that host".
   Something like:
   execute[nova:pause(vm)] :- vitrage:host_alarm(host), nova:servers(id=vm, 
hostId=host)

- monitoring policy: "whenever the host alarm is ON, all the VMs on that host 
belong to the violation table"
   violation(vm) :- vitrage:host_alarm(host), nova:servers(id=vm, hostId=host)

Here are the docs on writing such policies.
Basic policy:
http://docs.openstack.org/developer/congress/policy.html

Reactive policy:
http://docs.openstack.org/developer/congress/enforcement.html#manual-reactive-enforcement

Tim



On Thu, May 12, 2016 at 1:45 AM Masahito MUROI 
<muroi.masah...@lab.ntt.co.jp<mailto:muroi.masah...@lab.ntt.co.jp>> wrote:
Hi Alexey,

Thanks for clarified! I understood your use-case.

Anyway, as Tim mentioned before, implementing Vitrage driver seems to be
a good first step to integrate both.

best regards,
Masahito

On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote:
> Hi Masahito,
>
> In addition, I wanted to add that the reason Congress needs to get the data 
> from Vitrage by a pushing mechanism and not via polling, is so there won't be 
> a delay from when the event occurs and when Congress receives it. Using 
> polling, it will take a number of seconds (the polling interval time, 30 
> seconds by default) until Congress will receive the data.
>
> The reason of course why we need it, is to make the whole process work much 
> faster, and be consistent with other projects such as OPNFV Doctor (that 
> wants events to happen in less than 1 second).
>
> Alexey
>
>> -Original Message-
>> From: Weyl, Alexey (Nokia - IL) 
>> [mailto:alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>]
>> Sent: Tuesday, May 10, 2016 1:45 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
>> Collaboration
>>
>> Hi Masahito,
>>
>> Thanks for your question.
>>
>> There are two main reasons why we need to get alarms from Vitrage
>> initially.
>>
>> First, there are alarms that Vitrage generates ("deduced alarms") based
>> on its user-defined templates and topology. Also, there are alarms that
>> come from external sources outside of OpenStack, which Aodh and other
>> projects do not hold. This information could also be valuable for
>> Congress regardless of the RCA functionality.
>>
>> Second, since Vitrage retrieves alarms from multiple sources, the RCA
>> API takes as input the Vitrage-Id of the alarm. To know what that ID
>> is, you will need to first get the Alarms from Vitrage.
>>
>> Does this make sense? Would there be a different flow you think could
>> work?
>>
>> Best Regards,
>> Alexey
>>
>>> -Original Message-
>>> From: Masahito MUROI 
>>> [mailto:muroi.masah...@lab.ntt.co.jp<mailto:muroi.masah...@lab.ntt.co.jp>]
>>> Sent: Tuesday, May 10, 2016 11:00 AM
>>> To: 
>>> openstack-dev@lists.open

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi Masahito,

In addition, I wanted to add that the reason Congress needs to get the data 
from Vitrage by a pushing mechanism and not via polling, is so there won't be a 
delay from when the event occurs and when Congress receives it. Using polling, 
it will take a number of seconds (the polling interval time, 30 seconds by 
default) until Congress will receive the data.

The reason of course why we need it, is to make the whole process work much 
faster, and be consistent with other projects such as OPNFV Doctor (that wants 
events to happen in less than 1 second).

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Tuesday, May 10, 2016 1:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> Collaboration
> 
> Hi Masahito,
> 
> Thanks for your question.
> 
> There are two main reasons why we need to get alarms from Vitrage
> initially.
> 
> First, there are alarms that Vitrage generates ("deduced alarms") based
> on its user-defined templates and topology. Also, there are alarms that
> come from external sources outside of OpenStack, which Aodh and other
> projects do not hold. This information could also be valuable for
> Congress regardless of the RCA functionality.
> 
> Second, since Vitrage retrieves alarms from multiple sources, the RCA
> API takes as input the Vitrage-Id of the alarm. To know what that ID
> is, you will need to first get the Alarms from Vitrage.
> 
> Does this make sense? Would there be a different flow you think could
> work?
> 
> Best Regards,
> Alexey
> 
> > -Original Message-
> > From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
> > Sent: Tuesday, May 10, 2016 11:00 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> > Collaboration
> >
> > Hi Alexey,
> >
> > This use case sounds interesting. To be clarified it, I have a
> > question.
> >
> > On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
> > > Hi Tim,
> > >
> > > I agree – creating a datasource from Vitrage to Congress is the
> > > first step, and we should have some concrete use case in mind to
> > > help guide this process.
> > >
> > > The most straightforward use case I would suggest is when there is
> a
> > > problem on an instance that is caused by some problem on the
> > > physical host. Then:
> > >
> > > ·Vitrage will notify about an alarm on the instance, which Congress
> > > will receive
> > >
> > Why does Congress need to receive the alarm?  DataSouce Driver pulls
> > data from Vitrage, so it looks like Congress should only pull the
> > cause of the failure from Vitrage.
> >
> > Best regards,
> > Masahito
> >
> > > ·Congress can then call the Vitrage RCA API. The response will
> state
> > > that the cause of the instance alarm is the host alarm.
> > >
> > > ·Congress policy can define that in such a case, the instance
> should
> > > be migrated to (or healed on) a different physical host
> > >
> > > Does this seem like a good first step for you?
> > >
> > > Thanks,
> > >
> > > Alexey
> > >
> > > *From:*Tim Hinrichs [mailto:t...@styra.com]
> > > *Sent:* Saturday, May 07, 2016 2:43 AM
> > > *To:* OpenStack Development Mailing List (not for usage questions)
> > > *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-
> Congress
> > > Collaboration
> > >
> > > Hi Alexey,
> > >
> > > Thanks for the overview of how you see a Congress-Vitrage
> > > integration being valuable.
> > >
> > > I'd imagine that the right first step in this integration would be
> > > creating a new datasource driver within Congress to pull data from
> > > Vitrage.  It doesn't need to pull all the data in your list to
> > > start, but enough so that we can try writing policy over that data.
> > > It's helpful to have a policy in mind that you want to write and
> > > then set up the datasource driver to grab enough of the Vitrage
> data
> > > to write that policy.  Here are the relevant docs.
> > >
> > > Datasource drivers
> > >
> > > http://docs.openstack.org/developer/congress/cloudservices.html
> > >
> > > Writing policy
> > >
> > > http://docs.openstack.org/developer/congress/policy.html
> > >
> > > Le

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi Masahito,

Thanks for your question. 

There are two main reasons why we need to get alarms from Vitrage initially. 

First, there are alarms that Vitrage generates ("deduced alarms") based on its 
user-defined templates and topology. Also, there are alarms that come from 
external sources outside of OpenStack, which Aodh and other projects do not 
hold. This information could also be valuable for Congress regardless of the 
RCA functionality.

Second, since Vitrage retrieves alarms from multiple sources, the RCA API takes 
as input the Vitrage-Id of the alarm. To know what that ID is, you will need to 
first get the Alarms from Vitrage.

Does this make sense? Would there be a different flow you think could work?

Best Regards,
Alexey

> -Original Message-
> From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
> Sent: Tuesday, May 10, 2016 11:00 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> Collaboration
> 
> Hi Alexey,
> 
> This use case sounds interesting. To be clarified it, I have a
> question.
> 
> On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
> > Hi Tim,
> >
> > I agree – creating a datasource from Vitrage to Congress is the first
> > step, and we should have some concrete use case in mind to help guide
> > this process.
> >
> > The most straightforward use case I would suggest is when there is a
> > problem on an instance that is caused by some problem on the physical
> > host. Then:
> >
> > ·Vitrage will notify about an alarm on the instance, which Congress
> > will receive
> >
> Why does Congress need to receive the alarm?  DataSouce Driver pulls
> data from Vitrage, so it looks like Congress should only pull the cause
> of the failure from Vitrage.
> 
> Best regards,
> Masahito
> 
> > ·Congress can then call the Vitrage RCA API. The response will state
> > that the cause of the instance alarm is the host alarm.
> >
> > ·Congress policy can define that in such a case, the instance should
> > be migrated to (or healed on) a different physical host
> >
> > Does this seem like a good first step for you?
> >
> > Thanks,
> >
> > Alexey
> >
> > *From:*Tim Hinrichs [mailto:t...@styra.com]
> > *Sent:* Saturday, May 07, 2016 2:43 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> > Collaboration
> >
> > Hi Alexey,
> >
> > Thanks for the overview of how you see a Congress-Vitrage integration
> > being valuable.
> >
> > I'd imagine that the right first step in this integration would be
> > creating a new datasource driver within Congress to pull data from
> > Vitrage.  It doesn't need to pull all the data in your list to start,
> > but enough so that we can try writing policy over that data.  It's
> > helpful to have a policy in mind that you want to write and then set
> > up the datasource driver to grab enough of the Vitrage data to write
> > that policy.  Here are the relevant docs.
> >
> > Datasource drivers
> >
> > http://docs.openstack.org/developer/congress/cloudservices.html
> >
> > Writing policy
> >
> > http://docs.openstack.org/developer/congress/policy.html
> >
> > Let me know if you have any questions,
> >
> > Tim
> >
> > On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL)
> > <alexey.w...@nokia.com <mailto:alexey.w...@nokia.com>> wrote:
> >
> > Hi to all Vitrage and Congress contributors,
> >
> > We had a good introduction meeting in Austin and we (Vitrage)
> think
> > that we can have a good collaboration between the projects.
> >
> > Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds
> a
> > topology graph of all the entities in the system (physical,
> virtual
> > and application) from different datasources. It thus can enrich
> > Congress by providing more data about what is happening in the
> > system. Additionally, the Vitrage RCA and deduce alarms & states
> > mechanism can enhance the visibility of faults and how they
> > inter-relate.  By using this information Congress could then
> execute
> > different policies and perform more accurate actions.
> >
> > Another good property of Vitrage is that it can receive data also
> > from non-openstack sources, like Nagios, which monitor the
> physical
> > resources, including Switches (which are not modeled today in
> > 

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi Tim,

I agree – creating a datasource from Vitrage to Congress is the first step, and 
we should have some concrete use case in mind to help guide this process.

The most straightforward use case I would suggest is when there is a problem on 
an instance that is caused by some problem on the physical host. Then:


· Vitrage will notify about an alarm on the instance, which Congress 
will receive

· Congress can then call the Vitrage RCA API. The response will state 
that the cause of the instance alarm is the host alarm.

· Congress policy can define that in such a case, the instance should 
be migrated to (or healed on) a different physical host

Does this seem like a good first step for you?

Thanks,
Alexey

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Saturday, May 07, 2016 2:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

Hi Alexey,

Thanks for the overview of how you see a Congress-Vitrage integration being 
valuable.

I'd imagine that the right first step in this integration would be creating a 
new datasource driver within Congress to pull data from Vitrage.  It doesn't 
need to pull all the data in your list to start, but enough so that we can try 
writing policy over that data.  It's helpful to have a policy in mind that you 
want to write and then set up the datasource driver to grab enough of the 
Vitrage data to write that policy.  Here are the relevant docs.

Datasource drivers
http://docs.openstack.org/developer/congress/cloudservices.html

Writing policy
http://docs.openstack.org/developer/congress/policy.html

Let me know if you have any questions,
Tim



On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi to all Vitrage and Congress contributors,

We had a good introduction meeting in Austin and we (Vitrage) think that we can 
have a good collaboration between the projects.

Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a topology 
graph of all the entities in the system (physical, virtual and application) 
from different datasources. It thus can enrich Congress by providing more data 
about what is happening in the system. Additionally, the Vitrage RCA and deduce 
alarms & states mechanism can enhance the visibility of faults and how they 
inter-relate.  By using this information Congress could then execute different 
policies and perform more accurate actions.

Another good property of Vitrage is that it can receive data also from 
non-openstack sources, like Nagios, which monitor the physical resources, 
including Switches (which are not modeled today in OpenStack).

There are many ways in which Congress-Vitrage combination would be helpful. To 
take just one example:
a. If a physical Switch is down, Vitrage can raise deduced alarms on the 
connected hosts and on the virtual machines affected by this change in switch 
state.
b. Congress will then be notified by Vitrage about these alarms, which can set 
off Congress policies of migration.
c. Furthermore, due to the RCA functionality, Congress will be aware that the 
Switch error is the source of the problem, and can determine the best place to 
create new instances of the VMs so that this  switch fault will not impact the 
new instances.

As you can see, for each fault, we can use Vitrage to link it to other faults, 
and create alarms to reflect them. This is all done via Vitrage Templates, so 
the system is configurable to the needs of the user. Thus many more cases such 
as the example above could be thought of.

To summarize, Vitrage can enrich Congress with the following four features:
a. RCA
b. Deduced alarms
c. Physical, virtual and application layers
d. Graph structure and topology of the system that defines the connections and 
relationships between all entities on which we can run quick graph algorithms 
to decide different actions to perform

If you can think of additional use cases that can be used here, please share ☺

For more data about Vitrage and its insights please take a look here:
https://wiki.openstack.org/wiki/Vitrage

Best Regards,
Alexey Weyl

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

[openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi to all Vitrage and Congress contributors,

We had a good introduction meeting in Austin and we (Vitrage) think that we can 
have a good collaboration between the projects.

Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a topology 
graph of all the entities in the system (physical, virtual and application) 
from different datasources. It thus can enrich Congress by providing more data 
about what is happening in the system. Additionally, the Vitrage RCA and deduce 
alarms & states mechanism can enhance the visibility of faults and how they 
inter-relate.  By using this information Congress could then execute different 
policies and perform more accurate actions.

Another good property of Vitrage is that it can receive data also from 
non-openstack sources, like Nagios, which monitor the physical resources, 
including Switches (which are not modeled today in OpenStack).

There are many ways in which Congress-Vitrage combination would be helpful. To 
take just one example: 
a. If a physical Switch is down, Vitrage can raise deduced alarms on the 
connected hosts and on the virtual machines affected by this change in switch 
state. 
b. Congress will then be notified by Vitrage about these alarms, which can set 
off Congress policies of migration. 
c. Furthermore, due to the RCA functionality, Congress will be aware that the 
Switch error is the source of the problem, and can determine the best place to 
create new instances of the VMs so that this  switch fault will not impact the 
new instances.

As you can see, for each fault, we can use Vitrage to link it to other faults, 
and create alarms to reflect them. This is all done via Vitrage Templates, so 
the system is configurable to the needs of the user. Thus many more cases such 
as the example above could be thought of.

To summarize, Vitrage can enrich Congress with the following four features:
a. RCA
b. Deduced alarms
c. Physical, virtual and application layers
d. Graph structure and topology of the system that defines the connections and 
relationships between all entities on which we can run quick graph algorithms 
to decide different actions to perform

If you can think of additional use cases that can be used here, please share ☺

For more data about Vitrage and its insights please take a look here:
https://wiki.openstack.org/wiki/Vitrage

Best Regards,
Alexey Weyl

__
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] [aodh] Error when creating 2 event alarms with the same name

[Weyl, Alexey (Nokia - IL)]

Hi Fan,

The reason we need such a thing is because in Vitrage (which is an Openstack 
Root Cause Analysis Engine) we may raise a deduced alarms on (for example) each 
instance in the host, and we would like this name to be a human readable alarm 
(as you said yourself) without any random strings in order that it will be user 
and human friendly. Over time, the {seq-num} would grow and become less 
convenient and readable.

In addition,  we would like to give the users the ability to listen \ do a 
webhook on a specific alarm name (so if we will have a random string attached 
to each name, it won’t be possible). With your suggestion, we would need to at 
the very least be able to register to a set of alarms using regex – is this 
supported?

For more information about Vitrage:
https://wiki.openstack.org/wiki/Vitrage

Best regards,
Alexey

From: ZhiQiang Fan [mailto:aji.zq...@gmail.com]
Sent: Tuesday, May 03, 2016 6:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [aodh] Error when creating 2 event 
alarms with the same name

Alarm name unique constraint is only applied to each project, I don't remember 
the original cause, but in our customer's environment, alarm will be showed in 
the portal, with their name, no uuid, because user will be confused about such 
a random like string, then if alarm name can be duplicated, it is hard for them 
to differ between alarms.

So is there particular reason why you need to create duplicate name? can it be 
something like event-alarm-{event_type}-{seq_number} ?

Anyway, it is not so hard to remove this constraint, I just want to say that 
alarm name should be meaningful, otherwise it makes no difference with UUID: 
not human friendly.



On Tue, May 3, 2016 at 10:30 PM, Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
Hi,

First of all, I wanted to thank again to all the participants in the fruitful 
Aodh-Vitrage design session in Austin :)

I wanted to show in this email, the problem that we have when creating 2 event 
alarms with the same name.
Here is what I got in the command line:

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list
+--+--+---+--+-++-+--+
| Alarm ID | Name | State | Severity | Enabled | Continuous | Alarm condition | 
Time constraints |
+--+--+---+--+-++-+--+
+--+--+---+--+-++-+--+

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name 'Event 
Alarm 2' --state alarm --event-type 'my.event'
+---+--+
| Property  | Value|
+---+--+
| alarm_actions | []   |
| alarm_id  | 96f11384-abd7-4c11-b0a5-678646c11e79 |
| description   | Alarm when my.event event occurred.  |
| enabled   | True |
| event_type| my.event |
| insufficient_data_actions | []   |
| name  | Event Alarm 2|
| ok_actions| []   |
| project_id| bec13d47c22e45a9948981f5cb1ba45b |
| query | []   |
| repeat_actions| False|
| severity  | low  |
| state | alarm|
| type  | event|
| user_id   | d8812494489546aca8341af184eddd2c |
+---+--+

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list
+--+---+---+--+-++--+--+
| Alarm ID | Name  | State | Severity | 
Enabled | Continuous | Alarm condition  | Time constraints |
+--+---+---+--+-++--+--+
| 96f11384-abd7-4c11-b0a5-678646c11e79 | Event Alarm 2 | alarm | low  | 
True| False  | query: []| None |
|  |   |   |  | 
|| event_type: my.event |  |
+--+---+---+--+-++--+--+

stack@ubuntu-devstack:

Re: [openstack-dev] [vitrage] [aodh] Error when creating 2 event alarms with the same name

[Weyl, Alexey (Nokia - IL)]

Great!

We are currently starting to work on plans for Newton, and we have this on our 
list. See here: 
https://etherpad.openstack.org/p/vitrage-newton-planning 

We plan to start working on this soon :)

Alexey Weyl

> -Original Message-
> From: EXT Julien Danjou [mailto:jul...@danjou.info]
> Sent: Tuesday, May 03, 2016 6:03 PM
> To: Weyl, Alexey (Nokia - IL)
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [vitrage] [aodh] Error when creating 2
> event alarms with the same name
> 
> On Tue, May 03 2016, Weyl, Alexey (Nokia - IL) wrote:
> 
> > Do you think it is possible to drop the uniqueness of the alarm name
> > in Aodh (for the Vitrage use cases that we talked about in the design
> session)?
> 
> Should be doable yeah, it's really just a (badly written) check in the
> API.
> 
> Shoot us a patch! :)
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info

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

[openstack-dev] [vitrage] [aodh] Error when creating 2 event alarms with the same name

[Weyl, Alexey (Nokia - IL)]

Hi,

First of all, I wanted to thank again to all the participants in the fruitful 
Aodh-Vitrage design session in Austin :)

I wanted to show in this email, the problem that we have when creating 2 event 
alarms with the same name.
Here is what I got in the command line:

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list   
  
+--+--+---+--+-++-+--+
| Alarm ID | Name | State | Severity | Enabled | Continuous | Alarm condition | 
Time constraints |
+--+--+---+--+-++-+--+
+--+--+---+--+-++-+--+

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name 'Event 
Alarm 2' --state alarm --event-type 'my.event'
+---+--+
| Property  | Value    |
+---+--+
| alarm_actions | []   |
| alarm_id  | 96f11384-abd7-4c11-b0a5-678646c11e79 |
| description   | Alarm when my.event event occurred.  |
| enabled   | True |
| event_type    | my.event |
| insufficient_data_actions | []   |
| name  | Event Alarm 2    |
| ok_actions    | []   |
| project_id    | bec13d47c22e45a9948981f5cb1ba45b |
| query | []   |
| repeat_actions    | False    |
| severity  | low  |
| state | alarm    |
| type  | event    |
| user_id   | d8812494489546aca8341af184eddd2c |
+---+--+

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list
+--+---+---+--+-++--+--+
| Alarm ID | Name  | State | Severity | 
Enabled | Continuous | Alarm condition  | Time constraints |
+--+---+---+--+-++--+--+
| 96f11384-abd7-4c11-b0a5-678646c11e79 | Event Alarm 2 | alarm | low  | 
True    | False  | query: []    | None |
|      |   |   |  | 
    |    | event_type: my.event |  |
+--+---+---+--+-++--+--+

stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name 'Event 
Alarm 2' --state alarm --event-type 'my.event'
Alarm with name='Event Alarm 2' exists (HTTP 409) (Request-ID: 
req-b05dd105-fd23-47d3-a0b6-940bde6bcdd8)


Do you think it is possible to drop the uniqueness of the alarm name in Aodh 
(for the Vitrage use cases that we talked about in the design session)?

Best regards,
Alexey Weyl


__
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] Cinder Datasource

[Weyl, Alexey (Nokia - IL)]

Vitrage is a OpenStack project which supports Root Cause Analysis functionality 
for OpenStack, with support for raising additional deduced alarms and states. 
For this purpose Vitrage gathers information from multiple OpenStack projects 
about the state of the system, and how the different entities are related to 
one another.

This update was about first steps of adding Cinder into the Vitrage model - 
Vitrage can query Cinder to get the list of volumes and which instance they are 
attached to, and store this information in the Vitrage data model.

Based on your question, it is important to emphasize that Vitrage does not 
itself make changes to the system - it is concerned only in reflecting and 
analyzing what is happening and raising alarms / changing states as a result.

For more information on Vitrage, please see here:
https://wiki.openstack.org/wiki/Vitrage

Best Regards,
Alexey Weyl

> From: Erlon Cruz [mailto:sombra...@gmail.com] 
> Sent: Wednesday, April 13, 2016 3:43 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [vitrage] Cinder Datasource
>
> Can you give a bit more of context? Where is the design you mentioned? By 
> datasource you mean the Cinder service?
> There is already some work[1] to allow Cider to attach volumes in baremetal 
> servers.
>
>
> [1] https://blueprints.launchpad.net/cinder/+spec/use-cinder-without-nova
>
> On Tue, Apr 12, 2016 at 4:02 AM, Weyl, Alexey (Nokia - IL) 
> <alexey.w...@nokia.com> wrote:
> Hi,
>
> Here is the design of the Cinder datasource of Vitrage.
>
> Currently Cinder datasource is handling only Volumes.
> This datasource listens to cinder volumes notifications on the oslo bus, and 
> updates the topology accordingly.
> Currently Cinder Volume can be attached only to instance (Cinder design).
>
> Future Steps:
> We want to perform research on what other data we can bring from Cinder.
> For example:
> 1. To what zone we can connect the volume
> 2. To what image we can connect the volume
>
> Alexey

__
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] [telemetry][vitrage] Joint design sesssion in Austin

[Weyl, Alexey (Nokia - IL)]

As far as Vitrage team is concerned, 16:10-16:50 works best for us, but we can 
attend either session if needed.

Alexey Weyl

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Thursday, April 14, 2016 12:07 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [telemetry][vitrage] Joint design sesssion in Austin

Hi folks,

Vitrage doesn't have any track/session at the summit, and we Telemetry have a 
bunch of spare ones, so I figured we should use one to meet and chat a bit 
about how our projects can help each others. There should be some interesting 
evolution for Aodh going forward with the usage Vitrage is making of it.

We got 2 slots available on Thursday 28th April: 16:10-16:50 or 17:00:17:40. 
Would any of those fit the schedule of every interested?

Cheers,
--
Julien Danjou
# Free Software hacker
# https://julien.danjou.info

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

[openstack-dev] [vitrage] Change openstack.node to openstack.cluster

[Weyl, Alexey (Nokia - IL)]

Hi,

After some discussion, we have decided to change "openstack.node" to 
"openstack.cluster" as the "type" of the openstack cluster in the graph, to 
conform with the standard openstack terminology.

Alexey

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

[openstack-dev] [vitrage] Cinder Datasource

[Weyl, Alexey (Nokia - IL)]

Hi,

Here is the design of the Cinder datasource of Vitrage.

Currently Cinder datasource is handling only Volumes.
This datasource listens to cinder volumes notifications on the oslo bus, and 
updates the topology accordingly.
Currently Cinder Volume can be attached only to instance (Cinder design).

Future Steps:
We want to perform research on what other data we can bring from Cinder.
For example: 
1. To what zone we can connect the volume
2. To what image we can connect the volume

Alexey

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

[openstack-dev] [vitrage] Vitrage Demo - Alarms Use Case

[Weyl, Alexey (Nokia - IL)]

Hi,

We are happy to share with you all our second Vitrage demo, showing alarms 
imported from Nagios in Vitrage horizon UI. Here it is:

https://www.youtube.com/watch?v=w1XQATkrdmg

For more details about Vitrage, please visit our wiki here:

https://wiki.openstack.org/wiki/Vitrage 

Thanks,
Alexey

P.S. wait for our next demo which will show RCA and deduced alarms :)


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

[openstack-dev] [vitrage] Vitrage Demo - Get Topology Use Case

[Weyl, Alexey (Nokia - IL)]

Hi,

We are happy to share with you all our first Vitrage demo, showing the "get 
topology" api and horizon UI. Here it is:

https://www.youtube.com/watch?v=GyTnMw8stXQ=youtu.be

For more details about Vitrage, please visit our wiki here:

https://wiki.openstack.org/wiki/Vitrage 

Thanks,
Alexey



__
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