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