Open Stack

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