[openstack-dev] [ALU] [vitrage] datasource driver returns entities only?

Yujun Zhang zhangyujun+zte at gmail.com
Thu Dec 1 14:15:49 UTC 2016


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.weyl at 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+zte at 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-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/20161201/58bc2716/attachment.html>


More information about the OpenStack-dev mailing list