Hi, Yes, the entity_type is datasource_type, and the entity_id is the resources’ id which came from it’s datasource.
The example is correct, and just for the clarification, the “12345678” is the id of that entity in the datasource. Another clarification that I want to make sure, is that the static datasource (and actually each datasource), retrieves the transformer of the neighbor from the transformers dictionary that each transformer holds, and using the neighbors’ transformer it creates the placeholder of the neighbor (this is because each transformer knows exactly how to build it’s own placeholder). Alexey From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Monday, December 05, 2016 2:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] datasource driverreturnsentities only? 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.w...@nokia.com<mailto:alexey.w...@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+...@gmail.com<mailto:zhangyujun%2b...@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.w...@nokia.com<mailto: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<mailto:zhangyujun%2b...@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://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://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
