Open Stack

On Sat, Dec 31, 2016 at 5:08 PM, Doug Hellmann <doug at doughellmann.com> 
wrote:
> Excerpts from Matt Riedemann's message of 2016-12-30 16:23:24 -0600:
>>  While reviewing patches today to add versioned notifications for 
>> CRUD
>>  operations on aggregates and flavors I've come across some 
>> inconsistency.
>> 
>>  The existing non-versioned notification for aggregate.delete just 
>> sends
>>  the aggregate id, but the versioned notification is sending the 
>> whole
>>  aggregate object in the payload:
>> 
>>  
>> https://review.openstack.org/#/c/394512/9/doc/notification_samples/aggregate-delete-end.json
>> 
>>  But with the flavor-delete versioned notification, it's just 
>> sending the
>>  flavorid:
>> 
>>  
>> https://review.openstack.org/#/c/398171/16/doc/notification_samples/flavor-delete.json
>> 
>>  So which should we be doing? Either way you can correlate the id on 
>> the
>>  resource in the notification back to the full record if needed, but
>>  should we be sending the full object in the versioned notification
>>  payload while we have it? I don't much care either way which we do 
>> as
>>  long as we're consistent.

Thanks Matt for taking this up. I agree that we need to make a 
consistent solution.
The instance.delete notification also uses the same 
InstanceActionPayload as the instance.create. I think this is a good 
precedent to send the full payload at delete as well.

> 
> When we originally wrote ceilometer's notification consumption code,
> we ran into issues processing the data for delete notifications
> that only included identifiers.  IIRC, the primary issue at the
> time was with some of the CRUD operations in neutron, and we asked
> them to add all known data about objects to all notifications so
> the consumer could filter notifications based on those properties
> (maybe the receive wants to only pay attention to certain tenants,
> for example) and ensure it has the most current settings for an
> object as it is being deleted (useful for ensuring that a billing
> record includes the right flavor, for example).

Thanks Doug for adding the historic background. I think the use case 
you described are still valid so I propose to make a recommendation to 
emit a full payload at entity delete.

I proposed this recommendation to the notification devref [1].

[1]  https://review.openstack.org/415991

Cheers,
gibi


> 
> 
> Doug
> 
> __________________________________________________________________________
> 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