Your answer has made everything clear, Alexey. And I will take into consideration of the neighbor transformer in static datasource transformer implementation.
On Mon, Dec 5, 2016 at 2:22 PM Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > 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> 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] > *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> 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 > > __________________________________________________________________________ > 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