[openstack-dev] [vitrage] relationship_type in static_datasources

Yujun Zhang zhangyujun+zte at gmail.com
Tue Aug 30 02:08:41 UTC 2016


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>
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> 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]
>> *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> 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]
>> *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> 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://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://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://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/6e7a180a/attachment.html>


More information about the OpenStack-dev mailing list