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

2016-09-05 Thread Afek, Ifat (Nokia - IL) 


From: Yujun Zhang
Date: Monday, 5 September 2016 at 13:14

On Mon, Sep 5, 2016 at 5:49 PM Afek, Ifat (Nokia - IL) 
> wrote:

From: Yujun Zhang
Date: Friday, 2 September 2016 at 08:47
...
Cool.
Just please note that you can’t push it to master at the moment, as we are in 
feature freeze. Once stable/newton is created we will be able to start using 
the master branch for Ocata development.

When will it probably be?

stable/newton branch is supposed to be created after RC1, that is scheduled for 
September 15.


Also note that it means datasource configurations from Ocata will be different 
than the older versions, so we might want to mark them somehow, and keep the 
old parser for backwards compatibility.

OK, I'll take this into consideration.
__
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

2016-09-05 Thread Yujun Zhang 
On Mon, Sep 5, 2016 at 5:49 PM Afek, Ifat (Nokia - IL) 
wrote:

>
> From: Yujun Zhang
> Date: Friday, 2 September 2016 at 08:47
> ...
> Cool.
> Just please note that you can’t push it to master at the moment, as we are
> in feature freeze. Once stable/newton is created we will be able to start
> using the master branch for Ocata development.
>

When will it probably be?


> Also note that it means datasource configurations from Ocata will be
> different than the older versions, so we might want to mark them somehow,
> and keep the old parser for backwards compatibility.
>

OK, I'll take this into consideration.
__
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

2016-09-05 Thread Afek, Ifat (Nokia - IL) 

From: Yujun Zhang
Date: Friday, 2 September 2016 at 08:47

On Fri, Sep 2, 2016 at 2:44 AM Afek, Ifat (Nokia - IL) 
> wrote:
I think you have a point. We can indeed use the templates definitions for the 
static datasources as well.

If agreed by the team, I will get started to implement it.

@all, please share your opinions. All your comments are welcomed.

Cool.
Just please note that you can’t push it to master at the moment, as we are in 
feature freeze. Once stable/newton is created we will be able to start using 
the master branch for Ocata development.
Also note that it means datasource configurations from Ocata will be different 
than the older versions, so we might want to mark them somehow, and keep the 
old parser for backwards compatibility.

Ifat.

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

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

2016-09-01 Thread Yujun Zhang 
On Fri, Sep 2, 2016 at 2:44 AM Afek, Ifat (Nokia - IL) 
wrote:

> I think you have a point. We can indeed use the templates definitions for
> the static datasources as well.
>

If agreed by the team, I will get started to implement it.

@all, please share your opinions. All your comments are welcomed.

BTW, I noticed we already have a blueprint for this issue:
> https://blueprints.launchpad.net/vitrage/+spec/add-direction-to-physical-topology-relationships,
> but nobody has handled it so far.
>

This issue will be resolved without extra effort once we adopt the scenario
template for static resource. I can volunteer to handle it.

--
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] relationship_type in static_datasources

2016-09-01 Thread Afek, Ifat (Nokia - IL) 
I think you have a point. We can indeed use the templates definitions for the 
static datasources as well.
BTW, I noticed we already have a blueprint for this issue: 
https://blueprints.launchpad.net/vitrage/+spec/add-direction-to-physical-topology-relationships,
 but nobody has handled it so far.

Best Regards,
Ifat.

From: Yujun Zhang
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, 1 September 2016 at 05:51
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi, Ifat,

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

static configuration

- entities
  - {entity}
  - {entity}

for each entity

- name:
  id:
  relationship:
- {relationship}
- {relationship}

scenario templates

- definitions
  - entities
- {entity}
- {entity}
  - relationships
- {relationship}
- {relationship}

Though serving different purpose, they both

  1.  describe entities and relationships
  2.  use a dedicated key (id/template_id) to reference the items
  3.  include a source entity and target entity in relationship

The main differences between the two are


  *   scenario defines rules (entity and relationship matching), graph update 
is triggered when entities are added by datasource.
  *   static configuration defines rules and also add entities to graph

The rule definition are common to these two modules. We may define the static 
configuration using the same format as scenario template. And then simulate an 
entity discovery from the same file.

By reusing the template parsing engine and workflow, we may reduce the work in 
maintenance and bring in new features more easily.

We may discuss it further if anything unclear.

On Tue, Aug 30, 2016 at 11:07 PM Afek, Ifat (Nokia - IL) 
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi Yujun,

From: Yujun Zhang
Date: Monday, 29 August 2016 at 11:59

entities:
 - type: switch
   name: switch-1
   id: switch-1 # should be same as name
   state: available
   relationships:
 - type: nova.host
   name: host-1
   id: host-1 # should be same as name
   is_source: true # entity is `source` in this relationship
   relation_type: attached
 - type: switch
   name: switch-2
   id: switch-2 # should be same as name
   is_source: false # entity is `target` in this relationship
   relation_type: backup

I think that’s the idea, instead of making this assumption in the code.

But I wonder why the static physical configuration file use a different format 
from vitrage template definitions[1]

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst

What do you mean? The purpose of the templates is to describe the 
condition-action behaviour, wheres the purpose of the static configuration is 
to define resources to be added to vitrage graph. Can you please explain how 
you would make the formats more similar?

Best Regards,
Ifat.

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

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

2016-09-01 Thread Yujun Zhang 
Still failing after update the json file [1]

Yes, I think I shall need more help to understand how the mock_sync works.
@Elisha

And also the tox and tempest tests. @Alexey.

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

On Tue, Aug 30, 2016 at 4:02 PM Rosensweig, Elisha (Nokia - IL) <
elisha.rosensw...@nokia.com> wrote:

> Yes. Please add it to the file
>
>
>
>
> /workspace/dev/vitrage/vitrage/tests/resources/mock_configurations/driver/driver_switch_snapshot_dynamic.json
>
>
>
> under the "relationships" section, just like in your commit.
>
>
>
> If you need help understanding how to work with the mock_sync, let me know.
>
>
>
> Elisha
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Tuesday, August 30, 2016 9:59 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [vitrage] relationship_type in
> static_datasources
>
>
>
> I added a new key 'is_source' to static physical configuration [1] and the
> test currently fails.
>
>
>
> Not sure we need to update mock_sync or not.
>
>
>
> [1]
> https://review.openstack.org/#/c/362525/1/vitrage/tests/resources/static_datasources/switch_to_host_datasource.yaml
>
>
>
> On Tue, Aug 30, 2016 at 2:53 PM Rosensweig, Elisha (Nokia - IL) <
> elisha.rosensw...@nokia.com> wrote:
>
> What is the problem you are running into with mock_sync?
>
> Elisha
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Tuesday, August 30, 2016 5:09 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [vitrage] relationship_type in
> static_datasources
>
>
>
> Patch work in progress [1] but local test fails [2].
>
>
>
> It seems to be caused by the mock_sync.
>
>
>
> I'm still looking into it. Any help would be appreciated.
>
>
>
> [1] https://review.openstack.org/#/c/362525
>
> [2] http://pastebin.com/iepqxUAP
>
>
>
>
>
> On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> Thanks, Alexey. Point 1 and 3 are pretty clear.
>
>
>
> As for point 2, if I understand it correctly, you are suggesting to modify
> the static_physical.yaml as following
>
> entities:
>  - type: switch
>name: switch-1
>id: switch-1 # should be same as name
>state: available
>relationships:
>  - type: nova.host
>name: host-1
>id: host-1 # should be same as name
>
> *   is_source: true # entity is `source` in this relationship*
>
>relation_type: attached
>
>  - type: switch
>
>name: switch-2
>
>id: switch-2 # should be same as name
>
>
> *   is_source: false # entity is `target` in this relationship*   
> relation_type: backup
>
> But I wonder why the static physical configuration file use a different
> format from vitrage template definitions[1]
>
>
>
> [1]
> https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
>
>
>
> On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
> 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 th

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

2016-08-31 Thread Yujun Zhang 
Hi, Ifat,

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

static configuration

- entities
  - {entity}
  - {entity}

for each entity

- name:
  id:
  relationship:
- {relationship}
- {relationship}

scenario templates

- definitions
  - entities
- {entity}
- {entity}
  - relationships
- {relationship}
- {relationship}

Though serving different purpose, they both

   1. describe entities and relationships
   2. use a dedicated key (id/template_id) to reference the items
   3. include a source entity and target entity in relationship

The main differences between the two are


   - scenario *defines rules *(entity and relationship matching)*, *graph
   update is triggered when entities are added by datasource.
   - static configuration *defines rules* and also *add entities* to graph

The rule definition are common to these two modules. We may define the
static configuration using the same format as scenario template. And then
simulate an entity discovery from the same file.

By reusing the template parsing engine and workflow, we may reduce the work
in maintenance and bring in new features more easily.

We may discuss it further if anything unclear.

On Tue, Aug 30, 2016 at 11:07 PM Afek, Ifat (Nokia - IL) <
ifat.a...@nokia.com> wrote:

> Hi Yujun,
>
> From: Yujun Zhang
> Date: Monday, 29 August 2016 at 11:59
>
> entities:
>  - type: switch
>name: switch-1
>id: switch-1 # should be same as name
>state: available
>relationships:
>  - type: nova.host
>name: host-1
>id: host-1 # should be same as name*   is_source: true # entity is 
> `source` in this relationship
> *   relation_type: attached - type: switch   name: switch-2   
> id: switch-2 # should be same as name
> *   is_source: false # entity is `target` in this relationship*   
> relation_type: backup
>
>
> I think that’s the idea, instead of making this assumption in the code.
>
> But I wonder why the static physical configuration file use a different
> format from vitrage template definitions[1]
>
> [1]
> https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
>
>
> What do you mean? The purpose of the templates is to describe the
> condition-action behaviour, wheres the purpose of the static configuration
> is to define resources to be added to vitrage graph. Can you please explain
> how you would make the formats more similar?
>
> Best Regards,
> Ifat.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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

2016-08-30 Thread Afek, Ifat (Nokia - IL) 
Hi Yujun,

From: Yujun Zhang
Date: Monday, 29 August 2016 at 11:59

entities:
 - type: switch
   name: switch-1
   id: switch-1 # should be same as name
   state: available
   relationships:
 - type: nova.host
   name: host-1
   id: host-1 # should be same as name
   is_source: true # entity is `source` in this relationship
   relation_type: attached
 - type: switch
   name: switch-2
   id: switch-2 # should be same as name
   is_source: false # entity is `target` in this relationship
   relation_type: backup

I think that’s the idea, instead of making this assumption in the code.

But I wonder why the static physical configuration file use a different format 
from vitrage template definitions[1]

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst

What do you mean? The purpose of the templates is to describe the 
condition-action behaviour, wheres the purpose of the static configuration is 
to define resources to be added to vitrage graph. Can you please explain how 
you would make the formats more similar?

Best Regards,
Ifat.

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

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

2016-08-30 Thread Rosensweig, Elisha (Nokia - IL) 
Yes. Please add it to the file

/workspace/dev/vitrage/vitrage/tests/resources/mock_configurations/driver/driver_switch_snapshot_dynamic.json

under the "relationships" section, just like in your commit.

If you need help understanding how to work with the mock_sync, let me know.

Elisha

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Tuesday, August 30, 2016 9:59 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources

I added a new key 'is_source' to static physical configuration [1] and the test 
currently fails.

Not sure we need to update mock_sync or not.

[1] 
https://review.openstack.org/#/c/362525/1/vitrage/tests/resources/static_datasources/switch_to_host_datasource.yaml

On Tue, Aug 30, 2016 at 2:53 PM Rosensweig, Elisha (Nokia - IL) 
<elisha.rosensw...@nokia.com<mailto:elisha.rosensw...@nokia.com>> wrote:
What is the problem you are running into with mock_sync?
Elisha

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>]
Sent: Tuesday, August 30, 2016 5:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Patch work in progress [1] but local test fails [2].

It seems to be caused by the mock_sync.

I'm still looking into it. Any help would be appreciated.

[1] https://review.openstack.org/#/c/362525
[2] http://pastebin.com/iepqxUAP


On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote:
Thanks, Alexey. Point 1 and 3 are pretty clear.

As for point 2, if I understand it correctly, you are suggesting to modify the 
static_physical.yaml as following

entities:
 - type: switch
   name: switch-1
   id: switch-1 # should be same as name
   state: available
   relationships:
 - type: nova.host
   name: host-1
   id: host-1 # should be same as name

   is_source: true # entity is `source` in this relationship

   relation_type: attached

 - type: switch

   name: switch-2

   id: switch-2 # should be same as name

   is_source: false # entity is `target` in this relationship
   relation_type: backup
But I wonder why the static physical configuration file use a different format 
from vitrage template definitions[1]

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst

On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
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<mailto:zhangyujun%2b...@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 (N

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

2016-08-30 Thread Yujun Zhang 
I added a new key 'is_source' to static physical configuration [1] and the
test currently fails.

Not sure we need to update mock_sync or not.

[1]
https://review.openstack.org/#/c/362525/1/vitrage/tests/resources/static_datasources/switch_to_host_datasource.yaml

On Tue, Aug 30, 2016 at 2:53 PM Rosensweig, Elisha (Nokia - IL) <
elisha.rosensw...@nokia.com> wrote:

> What is the problem you are running into with mock_sync?
>
> Elisha
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Tuesday, August 30, 2016 5:09 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [vitrage] relationship_type in
> static_datasources
>
>
>
> Patch work in progress [1] but local test fails [2].
>
>
>
> It seems to be caused by the mock_sync.
>
>
>
> I'm still looking into it. Any help would be appreciated.
>
>
>
> [1] https://review.openstack.org/#/c/362525
>
> [2] http://pastebin.com/iepqxUAP
>
>
>
>
>
> On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang <zhangyujun+...@gmail.com>
> wrote:
>
> Thanks, Alexey. Point 1 and 3 are pretty clear.
>
>
>
> As for point 2, if I understand it correctly, you are suggesting to modify
> the static_physical.yaml as following
>
> entities:
>  - type: switch
>name: switch-1
>id: switch-1 # should be same as name
>state: available
>relationships:
>  - type: nova.host
>name: host-1
>id: host-1 # should be same as name
>
> *   is_source: true # entity is `source` in this relationship*
>
>relation_type: attached
>
>  - type: switch
>
>name: switch-2
>
>id: switch-2 # should be same as name
>
>
> *   is_source: false # entity is `target` in this relationship*   
> relation_type: backup
>
> But I wonder why the static physical configuration file use a different
> format from vitrage template definitions[1]
>
>
>
> [1]
> https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
>
>
>
> On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
> 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> 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]
> *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?
>
>
>
> --
>
> Yuju

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

2016-08-30 Thread Rosensweig, Elisha (Nokia - IL) 
What is the problem you are running into with mock_sync?
Elisha

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Tuesday, August 30, 2016 5:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Patch work in progress [1] but local test fails [2].

It seems to be caused by the mock_sync.

I'm still looking into it. Any help would be appreciated.

[1] https://review.openstack.org/#/c/362525
[2] http://pastebin.com/iepqxUAP


On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote:
Thanks, Alexey. Point 1 and 3 are pretty clear.

As for point 2, if I understand it correctly, you are suggesting to modify the 
static_physical.yaml as following

entities:
 - type: switch
   name: switch-1
   id: switch-1 # should be same as name
   state: available
   relationships:
 - type: nova.host
   name: host-1
   id: host-1 # should be same as name

   is_source: true # entity is `source` in this relationship

   relation_type: attached

 - type: switch

   name: switch-2

   id: switch-2 # should be same as name

   is_source: false # entity is `target` in this relationship
   relation_type: backup
But I wonder why the static physical configuration file use a different format 
from vitrage template definitions[1]

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst

On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) 
<alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>> wrote:
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<mailto:zhangyujun%2b...@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 us

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

2016-08-29 Thread Yujun Zhang 
Patch work in progress [1] but local test fails [2].

It seems to be caused by the mock_sync.

I'm still looking into it. Any help would be appreciated.

[1] https://review.openstack.org/#/c/362525
[2] http://pastebin.com/iepqxUAP


On Mon, Aug 29, 2016 at 4:59 PM Yujun Zhang <zhangyujun+...@gmail.com>
wrote:

> Thanks, Alexey. Point 1 and 3 are pretty clear.
>
> As for point 2, if I understand it correctly, you are suggesting to modify
> the static_physical.yaml as following
>
> entities:
>  - type: switch
>name: switch-1
>id: switch-1 # should be same as name
>state: available
>relationships:
>  - type: nova.host
>name: host-1
>id: host-1 # should be same as name*   is_source: true # entity is 
> `source` in this relationship
> *   relation_type: attached - type: switch   name: switch-2   
> id: switch-2 # should be same as name
> *   is_source: false # entity is `target` in this relationship*   
> relation_type: backup
>
> But I wonder why the static physical configuration file use a different
> format from vitrage template definitions[1]
>
> [1]
> https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
>
> On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
>> 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> 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]
>> *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> 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 A

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

2016-08-29 Thread Yujun Zhang 
Thanks, Alexey. Point 1 and 3 are pretty clear.

As for point 2, if I understand it correctly, you are suggesting to modify
the static_physical.yaml as following

entities:
 - type: switch
   name: switch-1
   id: switch-1 # should be same as name
   state: available
   relationships:
 - type: nova.host
   name: host-1
   id: host-1 # should be same as name*   is_source: true #
entity is `source` in this relationship
*   relation_type: attached - type: switch   name:
switch-2   id: switch-2 # should be same as name
*   is_source: false # entity is `target` in this relationship*
   relation_type: backup

But I wonder why the static physical configuration file use a different
format from vitrage template definitions[1]

[1]
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst

On Sun, Aug 28, 2016 at 4:14 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

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

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

2016-08-28 Thread Yujun Zhang 
Thanks for replying. See my comments inline.

On Sun, Aug 28, 2016 at 8:02 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
> Regarding the validation – I agree that we should implement it in another
> way, but as a first stage I think you can just remove it.
>

OK


> If you have some thoughts regarding the way to implement it, we will be
> happy to hear them. We thought about a yaml file per datasource, but didn’t
> design it yet.
>

No problem. I'll put it to open discuss once I have a proposal.


> BTW, did you notice the new API for template validation?
> https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst#template-validate
>
>

I'll have a look at it.
__
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

2016-08-28 Thread 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

2016-08-25 Thread Yujun Zhang 
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> 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]
> *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> 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
>
__
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

2016-08-24 Thread 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) 
<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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-08-24 Thread Yujun Zhang 
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] relationship_type in static_datasources

2016-08-24 Thread Afek, Ifat (Nokia - IL) 
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-dev] [vitrage] relationship_type in static_datasources

2016-08-21 Thread Yujun Zhang 
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