Open Stack

Thank you for your quick reply.

On 2016/08/01 23:31, McLellan, Steven wrote:
> In our (Searchlight's) ideal world, every notification about a resource
> would contain the full representation of that resource (for instance,
> equivalent to the API response for a resource), because it means that each
> notification on its own can be treated as the current state at that time
> without having to potentially handle multiple incremental updates to a
> resource. That isn't the case at the moment in lots of places either for
> historic reasons or because the implementation would be complex or
> expensive.
It seems current neutron implementation just adds API response body into 
notification's payload. Therefore, in Neutron, the payload depends on 
each extension's implementation and it's not surely the full 
representation of that resource now.

> With tags as an example, while I understand why that's the case (the API
> treats tags as a separate entity and it's implemented as a separate
> database table) it doesn't make a lot of logical sense to me to treat
> adding a tag to a network as a separate event from (for instance) renaming
> it. In both cases as far as a consumer of notifications is concerned, some
> piece of information about the network changed. That said, it's obviously
> up to each project how they generate notifications for events (and thanks
> for taking this one on), and I understand why you don't want to add a huge
> amount of complexity to the plugin code.
Thanks for summarizing main points. That's right.

> One thing that would be useful is if adding a tag changes the resource's
> 'updated_at', and have that included in the notification. That allows us
> to determine whether a notification is more up-to-date than a request at
> some point in the near past to the API. I guess though that this will also
> be difficult in terms of how the plugin interacts with the core code?
This is another point. I can understand your opinion. I will try to add 
'updated_at' into tag notification's payload in future. However, now tag 
and other extensions resources cannot be used with the 
feature(timestamp). I think that it's next step after implementing tag 
notification.

Thanks,
Hirofumi


> Thanks,
>
> Steve
>
> On 8/1/16, 3:33 AM, "Hirofumi Ichihara" <ichihara.hirofumi at lab.ntt.co.jp>
> wrote:
>
>> Hi,
>>
>> I'm trying to solve a issue[1, 2] which doesn't send a notification when
>> Tag is updated. I'm worried about the payload. My solution just outputs
>> added tag, resource type, and resource id as payload. However, there was
>> a comment which mentioned the payload should have more information. I
>> guess that it means, for instance, when we added a tag to a network, we
>> can accept the network's name, status, description, share, and so on as
>> notification payload.
>>
>> If Tag plugin already has such information, I might not disagree the
>> opinion but the plugin doesn't have it now. So we will need to add
>> reading DB process to each Tag API for notification only. I wouldn't go
>> as far as to add such extra process.
>>
>> Is my current solution enough information for searchlight or other
>> notification systems?
>>
>> [1]: https://bugs.launchpad.net/neutron/+bug/1560226
>> [2]: https://review.openstack.org/#/c/298133/
>>
>> Thanks,
>> Hirofumi
>>
>>
>>
>> __________________________________________________________________________
>> 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
>
>