[openstack-dev] [vitrage] relationship_type in static_datasources

Yujun Zhang zhangyujun+zte at gmail.com
Thu Sep 1 06:40:36 UTC 2016


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.rosensweig at 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+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> wrote:
>
> What is the problem you are running into with mock_sync?
>
> Elisha
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+zte 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>
> 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
>
> __________________________________________________________________________
> 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/20160901/e1c38489/attachment-0001.html>


More information about the OpenStack-dev mailing list