Re: [openstack-dev] [neutron] [searchlight] What do we need in notification payload?

[Hirofumi Ichihara]

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" 
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-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

Re: [openstack-dev] [neutron] [searchlight] What do we need in notification payload?

[McLellan, Steven]

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. 

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.

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?

Thanks,

Steve

On 8/1/16, 3:33 AM, "Hirofumi Ichihara" 
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-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-dev] [neutron] [searchlight] What do we need in notification payload?

[Hirofumi Ichihara]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev