Need more data added for RBAC policy notifications

[Rick Aulino]

For the Searchlight project, we are receiving notifications for the RBAC policy commands.

    rbac-create
    rbac-delete

The payload for rbac_policy.create.end is complete and allows Searchlight to update our state to reflect the policy changes.

The payload for rbac_policy.delete.end is not as complete. The payload we receive is:

{
"event_type": "rbac_policy.delete.end",
"payload":
{ "rbac_policy_id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }

}

Since the RBAC policy is being deleted, we cannot query the details of the policy through the Neutron API using the policy ID. Doing so results in a race condition where the majority of the time the policy has already been deleted.

This means we need to store the details of the policy upon rbac_policy.create.end time, which requires extraneous state in Searchlight.

We would like a change to the rbac_policy.delete.end payload to include all policy's details. Mirroring the same information provided by the rbac_policy.create.end notification:

{
"event_type": "rbac_policy.delete.end",
"payload":
{ "target_tenant": "admin", "tenant_id": "c4b424b17cc04cefa7211b40c5c893c2", "object_type": "network", "object_id": "64f00d1c-a6b6-4c00-a800-10eb9360a976", "action": "access_as_shared", "id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }

}

At a bare minimum, we would need "tenant_id", "object_id" and "id" to be returned.

[Ihar Hrachyshka (ihar-hrachyshka)]

It's actually not clear to me why it does not happen in a (similar) way that you expect. At least my reading of _delete() implementation in neutron/api/v2/base.py suggests that the payload should contain more than just an ID even for delete.end notifications.

Do we by chance see the same stripped payload for other resources? If so, it could be as well some general bug and not a feature request.

[Armando Migliaccio (armando-migliaccio)]

I am not sure this needs to be treated as an RFE. I recall that this type of request come up before. I suppose we can tweak the payload the way desidered. Bear in mind that we don't expect message put on the bus as stable/public contract.

[Lajos Katona (lajos-katona)]

We can close this as I see, the notifications are much more detailed since, for rbac:

INFO oslo.messaging.notification.rbac_policy.create.end [None req-b98f02a2-b65c-4331-ab51-966186dc7fd0 None admin] {"message_id": "15f5fe6b-5254-4b67-9303-6250119376d1", "publisher_id": "network.newtaas", "event_type": "rbac_policy.create.end","priority": "INFO", "payload": {"rbac_policy": {"id": "4f11ca6e-9c98-4dcf-8797-cd8ce13103d0", "project_id": "6fa72026f37a480d8727409aa7b3f7b6", "action": "access_as_shared", "object_id":"5c93e716-b195-4f91-915a-7120bcddec39", "target_tenant": "*", "object_type": "network", "tenant_id": "6fa72026f37a480d8727409aa7b3f7b6"}}, "timestamp": "2023-11-15 16:19:36.764328"}

and for rbac delete:

INFO oslo.messaging.notification.rbac_policy.delete.end [None req-6a29b809-9c27-4577-86e9-9a486178b49d None admin] {"message_id": "1a8ff78c-4be5-4582-82b4-0518434053b7", "publisher_id":"network.newtaas","event_type": "rbac_policy.delete.end", "priority": "INFO", "payload": {"rbac_policy_id": "4f11ca6e-9c984dcf-8797-cd8ce13103d0", "rbac_policy": {"id": "4f11ca6e-9c98-4dcf-8797-cd8ce13103d0", "project_id":"6fa72026f37a480d8727409aa7b3f7b6", "action": "access_as_shared", "object_id": "5c93e716-b195-4f91-915a7120bcddec39", "target_tenant": "*", "object_type": "network", "tenant_id":"6fa72026f37a480d8727409aa7b3f7b6"}}, "timestamp": "2023-11-15 16:20:30.891196"}