Update patch set 12

Patch Set 12:

(1 comment)

Patch-set: 12

cc2a5f4aaa3e1cc5c15809dd1618bf6a7cd1a0f8

@@ -141,6 +141,30 @@
       "revId": "cc2a5f4aaa3e1cc5c15809dd1618bf6a7cd1a0f8",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": false
+    },
+    {
+      "key": {
+        "uuid": "3f79a3b5_0527a7b5",
+        "filename": "specs/rocky/approved/monasca-events-publishing.rst",
+        "patchSetId": 12
+      },
+      "lineNbr": 431,
+      "author": {
+        "id": 11580
+      },
+      "writtenOn": "2018-08-07T19:20:22Z",
+      "side": 1,
+      "message": "Ah, \"tenant_id\" and \"user_id\" fields are available in \"payload\" section of the notification, and these notifications are generated by the service itself. \n\nThere is no additional \"Openstack-operator-agent\" like component or functionality required to fetch that data from the service and publish to monasca event api on behalf of original tenant. \n\nCeilometer publishing pipeline simply extracts these \"tenant_id\" and \"user_id\" fields from the \"payload\" and makes those fields available as \"tenant_id\" and \"user_id\" traits, which would then be mapped to \"dimensions.project_id\" and \"dimensions.userid\" fields in monasca events format.\n\nThe role-based access was how it was implemented in Ceilometer V2 API, thats why I thought you are referring to role based access when querying for the data via Monasca Events API.(BTW, just an FYI Ceilometer V2 API has now been removed since Queens)\n\nSo in short the original tenant_id and user_id is available in payload of the notification, and will make its way to \"dimensions.tenant_id\" and \"dimensions.user_id\" in Monasca Event.",
+      "parentUuid": "3f79a3b5_f3d91c83",
+      "range": {
+        "startLine": 431,
+        "startChar": 47,
+        "endLine": 431,
+        "endChar": 96
+      },
+      "revId": "cc2a5f4aaa3e1cc5c15809dd1618bf6a7cd1a0f8",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
     }
   ]
 }