catalog/core notifications something wrong

[zouyee]

notification.Audit.update needed to be changed from service_id to ref['id'],when u call create_service function with service_id and service_ref parameters, because service_id may be not equal to ref['id'], we should use ref['id'] instead of service_id when calling notifications.Audit.updated function

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/247324

[zouyee (zoues)]

notification.Audit.update needed to be changed from service_id to ref['id'],
when u call create_service function with service_id and service_ref parameters,
because service_id may be not equal to ref['id'],
we should use ref['id'] instead of service_id
when calling 'notifications.Audit.updated'.Because the function of
test_create_service in test_notifications has implemted with service_ref['id'],
I do not need to change the test code.

[Henry Nash (henry-nash)]

I don't see how in practice this can happen. As far as I can see, our controllers always set the service_id to be a uuid and equal to the service_ref['id'].

I agree that technically we should be using the ref, so I'd say this is a low priority to fix

[Henry Nash (henry-nash)]

Is this actually a bug? ALL our manager create methods work this way - by assuming the entity ID parameter is equal to the ID in the ref passed. They all use the entity ID for notification.

If there is an issue it is that we shouldn't really be passing the entity ID as well as the ref (that contains the same entity ID) into the manager create call. I don't really know what we did that...maybe just to make all manager calls have the entity ID as the first parameter?

[Steve Martinelli (stevemar)]

until we see a real case where the ID seen in the notification does NOT match the ID of the resource, this isn't a bug, it's just a convention we use in the code

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Stanek (<email address hidden>) on branch: master
Review: https://review.openstack.org/247324
Reason: I agree with everyone here that this isn't really a bug. If there is disagreement then we can take that discussion to the bug.

[Steve Martinelli (stevemar)]

unassigning due to inactivity