Open Stack

Thanks for clarification.

Is `entity_type` equivalent to datasource type? And `entity_id` should be
interpreted by the related datasource, is that right.

For example, "RESOURCE:nova.host:12345678" is from `nova.host` datasource
and `12345678` is how `nova.host` identify a resource.

--
Yujun

On Sun, Dec 4, 2016 at 4:35 PM Weyl, Alexey (Nokia - IL) <
alexey.weyl at nokia.com> wrote:

> Hi Yujun,
>
>
>
> I see the confusion.
>
>
>
> The way we find the resource entity (it’s different than finding the alarm
> entity, but it’s ok because the static datasource is defining relationships
> between resource entities) is in the following way:
>
> Each entity has a vitrage_id which is defined by
> “RESOURCE:<entity_type>:<entity_id> (we are planning in the very near
> future to change the vitrage_id to be a UUID, but at the moment your change
> doesn’t need to refer to that), for example: “RESOURCE:nova.host:12345678”.
>
>
>
> So in this way all you need to know about the other entity is it’s
> <entity_type> and it’s <entity_id>.
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+zte at gmail.com]
> *Sent:* Thursday, December 01, 2016 4:16 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver
> returnsentities only?
>
>
>
> 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
>
> __________________________________________________________________________
> 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/20161205/94d73acb/attachment.html>