[openstack-dev] [vitrage] relationship_type in static_datasources
Rosensweig, Elisha (Nokia - IL)
elisha.rosensweig at nokia.com
Tue Aug 30 07:53:53 UTC 2016
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+zte at 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.rosensweig at nokia.com<mailto:elisha.rosensweig at nokia.com>> wrote:
What is the problem you are running into with mock_sync?
Elisha
From: Yujun Zhang [mailto:zhangyujun+zte at gmail.com<mailto:zhangyujun%2Bzte at 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+zte at gmail.com<mailto:zhangyujun%2Bzte at 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.weyl at nokia.com<mailto:alexey.weyl at 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+zte at gmail.com<mailto:zhangyujun%2Bzte at 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.weyl at nokia.com<mailto:alexey.weyl at 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+zte at gmail.com<mailto:zhangyujun%2Bzte at 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.afek at nokia.com<mailto:ifat.afek at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160830/9b15b6a1/attachment.html>
More information about the OpenStack-dev
mailing list