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
