Another question, how do we describe an entity from *another* datasource in static datasource config?
In the test resources of static_physical datasource, it seems to be referred as following. Does it means that it will be `nova.host` to find the matched resource? If so, how will `nova.host` identify the resource, by name or by id? relationships: - type: nova.host name: host-2 id: 2 relation_type: attached On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi Yujun, > > > > Get_all does returns a list of entities to be sent. > > > > Each event that is sent from the driver to the processor contains also all > the details of the neighbors that it connects to. > > For example, the event and data that we receive from nova about an > instance also contains the host (compute) that it sits on, and that is how > we decide to connect it to the correct host. > > > > I think it is ok that the event of static (from driver to the processor) > will contain for each entity it neighbors that it is supposed to be > connected to. > > > > BR, > > Alexey > > > > *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com] > *Sent:* Thursday, December 01, 2016 3:20 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [ALU] [openstack-dev] [vitrage] datasource driver returns > entities only? > > > > During the implementation of static datasource driver[1], I got a question > on the return format of `get_all` method. > > > > If I understand correctly, it should return a list of entities to be sent > to the queue. Does it infer that the relationship should be embedded in > entity, just like the legacy static_physical datasource? > > > > Suppose a link between two switches are created, how should we emit this > change in `get_all` or `get_changes`? > > > > Currently I made a compromise by emitting the relationship as an update of > the connected entity. This is not very elegant and it seems we are going > back to the legacy static_physical datasource. > > > > [1] https://review.openstack.org/#/c/405354/ > > -- > > 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 >
__________________________________________________________________________ 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