)]}'
{"specs/approved/notifications.rst":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"cb1a657ec2f1a3f6cffcf56a068429c76494a66c","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."},{"line_number":84,"context_line":"  * \"fail\" will be used when an action fails, regardless of whether the action"},{"line_number":85,"context_line":"    is immediate or not."},{"line_number":86,"context_line":"  * \"done\" will be used when an action that is immediate succeeds."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"  event_type will have a base class defining these fields, with"},{"line_number":89,"context_line":"  subclasses for each type of event that occurs. These subclasses will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa7ab95a_3ba11bf9","line":86,"updated":"2016-09-01 16:58:19.000000000","message":"I thought we had discussed using \"success\" for this? I don\u0027t like \"done\" because it could be misconstrued as the opposite of start (start-\u003edone makes as much sense as start-\u003eend).","commit_id":"cc2d3d79e75cdb8fd2de6c71abbf48d6b170e4b9"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"25b6199cc08f678923a40a9238774307ffc3e846","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."},{"line_number":84,"context_line":"  * \"fail\" will be used when an action fails, regardless of whether the action"},{"line_number":85,"context_line":"    is immediate or not."},{"line_number":86,"context_line":"  * \"done\" will be used when an action that is immediate succeeds."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"  event_type will have a base class defining these fields, with"},{"line_number":89,"context_line":"  subclasses for each type of event that occurs. These subclasses will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa7ab95a_d93d942c","line":86,"in_reply_to":"fa7ab95a_3ba11bf9","updated":"2016-09-01 18:44:03.000000000","message":"Done","commit_id":"cc2d3d79e75cdb8fd2de6c71abbf48d6b170e4b9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"a4cf8a3ac7ab8925486d2fd59ad1578b453a0e76","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  This will be followed by the object that\u0027s being acted on, optionally the"},{"line_number":78,"context_line":"  field of the object being acted on, a descriptor of the action being taken,"},{"line_number":79,"context_line":"  and the status of the action (\"start\", \"end\", \"fail\", or \"success\"). These"},{"line_number":80,"context_line":"  statuses will have the following semantics:"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"  * \"start\" will be used when an action that is not immediate begins."},{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_0fe08a95","line":80,"updated":"2016-09-01 19:38:45.000000000","message":"Maybe somewhere, mention that an event_type string has the format baremetal.\u003cobject\u003e.\u003caction\u003e.\u003cstatus\u003e\n\nso \u003cobject\u003e is the part above, \"the object that\u0027s being acted on, optional field of the object being acted on\" ? Or just \"the object that\u0027s being acted on\". With \u0027optional field..\u0027 being part of the \u003caction\u003e ?\n\ncuz if i look at examples below, eg baremetal.node.power_set.start, i can interpret the object as being \u0027node\u0027, or the object as being \u0027node power\u0027, and the action being \u0027set\u0027 or \u0027power_set\u0027.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"e2ffe4085cfb73bb96fb29c5c9fe2c5ad498190d","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  This will be followed by the object that\u0027s being acted on, optionally the"},{"line_number":78,"context_line":"  field of the object being acted on, a descriptor of the action being taken,"},{"line_number":79,"context_line":"  and the status of the action (\"start\", \"end\", \"fail\", or \"success\"). These"},{"line_number":80,"context_line":"  statuses will have the following semantics:"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"  * \"start\" will be used when an action that is not immediate begins."},{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_2db9d615","line":80,"in_reply_to":"fa7ab95a_0fe08a95","updated":"2016-09-01 20:32:53.000000000","message":"Good point, I didn\u0027t realize this wasn\u0027t in the spec. I think it\u0027s implicit based on this paragraph and the following one, but I will make it more explicit below.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"6414f5b44d68983f819db012d17386a03f2f725c","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  * \"baremetal.node.power_set.start\""},{"line_number":96,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_12e2712f","line":98,"updated":"2016-09-01 19:43:31.000000000","message":"why is it \u0027power_set\u0027 and \u0027state_change\u0027? Why aren\u0027t they both the same \u0027set\u0027 or \u0027change\u0027?\n\nAlso, I think in the CRUD spec, it was s/state/provision_state/. Would /state/provision/ be sufficient? eg baremetal.node.provision_set.\u003cstatus\u003e","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"e2ffe4085cfb73bb96fb29c5c9fe2c5ad498190d","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  * \"baremetal.node.power_set.start\""},{"line_number":96,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_cde86ae5","line":98,"in_reply_to":"fa7ab95a_12e2712f","updated":"2016-09-01 20:32:53.000000000","message":"We discussed in IRC that this should be power_set so that we could make it consistent between those two notifications: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2016-08-30.log.html#t2016-08-30T19:51:54\n\nI forgot to update the state_change ones and will update them here, thanks.\n\nThese are just potential examples, though, so if we want to change it in the future, we can update the CRUD spec instead of this perhaps.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"a4cf8a3ac7ab8925486d2fd59ad1578b453a0e76","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* payload will be a versioned object related to the notification topic. This"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_af26becb","line":99,"updated":"2016-09-01 19:38:45.000000000","message":"might be bikeshedding at this point, but wondering if we can use something other than \u0027start\u0027 to avoid confusing that action with the status of the same name.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"e2ffe4085cfb73bb96fb29c5c9fe2c5ad498190d","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* payload will be a versioned object related to the notification topic. This"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_4da29aaf","line":99,"in_reply_to":"fa7ab95a_af26becb","updated":"2016-09-01 20:32:53.000000000","message":"Yeah, these are just potential names. I\u0027ll put \"baremetal.conductor.init.success\", that may be better.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"a4cf8a3ac7ab8925486d2fd59ad1578b453a0e76","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* payload will be a versioned object related to the notification topic. This"},{"line_number":103,"context_line":"  should include relevant information about the event being notified on. For"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_4f1e1271","line":100,"updated":"2016-09-01 19:38:45.000000000","message":"this doesn\u0027t make sense to me. if the conductor successfully stops, why would the status be \u0027fail\u0027?\n\nDo you think .conductor notifications are useful?","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"e2ffe4085cfb73bb96fb29c5c9fe2c5ad498190d","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  * \"baremetal.node.state_change.start\""},{"line_number":98,"context_line":"  * \"baremetal.node.state_change.end\""},{"line_number":99,"context_line":"  * \"baremetal.conductor.start.success\""},{"line_number":100,"context_line":"  * \"baremetal.conductor.stop.fail\""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* payload will be a versioned object related to the notification topic. This"},{"line_number":103,"context_line":"  should include relevant information about the event being notified on. For"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_0d9df265","line":100,"in_reply_to":"fa7ab95a_4f1e1271","updated":"2016-09-01 20:32:53.000000000","message":"Good point. I\u0027ll switch this to \"success\".\n\nI think they would be useful. I\u0027ve seen cases where nodes stay locked or get in weird states if a conductor falls over / is stopped. It would be nice to allow an external service to have some alerting around this.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"e2ffe4085cfb73bb96fb29c5c9fe2c5ad498190d","unresolved":false,"context_lines":[{"line_number":305,"context_line":"* Developer documentation will be added for how to add new notifications or"},{"line_number":306,"context_line":"  modify existing notifications"},{"line_number":307,"context_line":"* Document an example of what an emitted notification will look like"},{"line_number":308,"context_line":"* Documentation should be added for each notification indicating when it\u0027s"},{"line_number":309,"context_line":"  expected to be emitted"},{"line_number":310,"context_line":""},{"line_number":311,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_0d2df2a7","line":308,"updated":"2016-09-01 20:32:53.000000000","message":"Ruby - this is the new requirement for documentation about notifications that we discussed in IRC. This should help clarify when \"start\" and \"end\" happen on a per-notification basis.","commit_id":"6809d02d2b5d2fa574b419ef50a8047c4d6b65bb"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"7cd753efd6887ab61411d0b5bbd85cba8bd54eb1","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  Each string will start with \"baremetal.\" to distinguish ironic notifications"},{"line_number":75,"context_line":"  from other notifications on the message bus."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"  This will be followed by the object that\u0027s being acted on, optionally the"},{"line_number":78,"context_line":"  field of the object being acted on, a descriptor of the action being taken,"},{"line_number":79,"context_line":"  and the status of the action (\"start\", \"end\", \"fail\", or \"success\"). These"},{"line_number":80,"context_line":"  statuses will have the following semantics:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa7ab95a_7eb1c600","line":77,"updated":"2016-09-01 21:39:45.000000000","message":"I think this paragraph ought to be clearer. In particular, it isn\u0027t clear where the \"optionally the field of the object being acted on\" -- is it part of the \u003cobject\u003e, or part of the \u003caction\u003e, or a separate \u003cfield\u003e part of the event type?\n\nI\u0027m guessing \u003caction\u003e based on below examples.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":7711,"name":"Yuriy Zveryanskyy","email":"yzveryanskyy@mirantis.com","username":"yuriyz"},"change_message_id":"0030016fc93fafe85c63f130eb0537a70f0ead0d","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  Each string will start with \"baremetal.\" to distinguish ironic notifications"},{"line_number":75,"context_line":"  from other notifications on the message bus."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"  This will be followed by the object that\u0027s being acted on, optionally the"},{"line_number":78,"context_line":"  field of the object being acted on, a descriptor of the action being taken,"},{"line_number":79,"context_line":"  and the status of the action (\"start\", \"end\", \"fail\", or \"success\"). These"},{"line_number":80,"context_line":"  statuses will have the following semantics:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa7ab95a_3523c3be","line":77,"range":{"start_line":77,"start_character":61,"end_line":77,"end_character":71},"updated":"2016-09-02 10:32:39.000000000","message":"Is there any optionally field?","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"55d5617b6bb7b303b0c03d69afe57d173ae44457","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  Each string will start with \"baremetal.\" to distinguish ironic notifications"},{"line_number":75,"context_line":"  from other notifications on the message bus."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"  This will be followed by the object that\u0027s being acted on, optionally the"},{"line_number":78,"context_line":"  field of the object being acted on, a descriptor of the action being taken,"},{"line_number":79,"context_line":"  and the status of the action (\"start\", \"end\", \"fail\", or \"success\"). These"},{"line_number":80,"context_line":"  statuses will have the following semantics:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_2f67194e","line":77,"range":{"start_line":77,"start_character":61,"end_line":77,"end_character":71},"in_reply_to":"fa7ab95a_3523c3be","updated":"2016-09-06 22:07:09.000000000","message":"Good point, I forgot to update this part. I originally meant for the \"field\" to be part of \u003caction\u003e. There are no optional parameters when creating an event type.\n\nWhat do you think about the next patch set? I removed the reference to the object field and just said that the action needs to be described.\n\nI think realistically reviewers will have to determine whether an event_type is descriptive enough or not. If one particular field of an object is being modified by some action, it might be useful to include that in the description.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"63adb83341d3a0a97f536ac60dd3bc3648027378","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"  * \"start\" will be used when an action that is not immediate begins."},{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."},{"line_number":84,"context_line":"  * \"fail\" will be used when an action fails, regardless of whether the action"},{"line_number":85,"context_line":"    is immediate or not."},{"line_number":86,"context_line":"  * \"success\" will be used when an action that is immediate succeeds."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_8e84b5d4","line":84,"updated":"2016-09-06 16:38:43.000000000","message":"I see that nova uses \u0027error\u0027 [1]. And that nova doesn\u0027t always emit an \u0027error\u0027. What do you think about being consistent with nova and using \u0027error\u0027.  We can document which events have a .error or not.\n\n[1] https://wiki.openstack.org/wiki/SystemUsageData","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"55d5617b6bb7b303b0c03d69afe57d173ae44457","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"  * \"start\" will be used when an action that is not immediate begins."},{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."},{"line_number":84,"context_line":"  * \"fail\" will be used when an action fails, regardless of whether the action"},{"line_number":85,"context_line":"    is immediate or not."},{"line_number":86,"context_line":"  * \"success\" will be used when an action that is immediate succeeds."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_0f97b5ec","line":84,"in_reply_to":"9a89bdaa_8e84b5d4","updated":"2016-09-06 22:07:09.000000000","message":"I preferred \"fail\" because sometimes we\u0027ll want to notify that an action failed, but it\u0027s not necessarily indicative of a bug on ironic\u0027s part. For example, if a node power state change failed because a node\u0027s BMC is unreachable, ironic failed to change the power state, but it\u0027s behaving as one would expect it to in the case of hardware failure.\n\nI don\u0027t really care which word we use though, so I\u0027ll make this \"error\" to be consistent with nova.\n\n+1 to docs for which events have error or not. I expect the documentation being added for each notification to be clear about what an operator should expect to see on the message bus.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"63adb83341d3a0a97f536ac60dd3bc3648027378","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  * \"end\" will be used when an action that is not immediate succeeds."},{"line_number":84,"context_line":"  * \"fail\" will be used when an action fails, regardless of whether the action"},{"line_number":85,"context_line":"    is immediate or not."},{"line_number":86,"context_line":"  * \"success\" will be used when an action that is immediate succeeds."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"  event_type will have a base class defining these fields, with"},{"line_number":89,"context_line":"  subclasses for each type of event that occurs. These subclasses will be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_8e5bd586","line":86,"updated":"2016-09-06 16:38:43.000000000","message":"nova doesn\u0027t do this, but I like having it.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"63adb83341d3a0a97f536ac60dd3bc3648027378","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  A few examples of potential event_type strings:"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"  * \"baremetal.node.power_set.start\""},{"line_number":100,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":101,"context_line":"  * \"baremetal.node.provision_set.start\""},{"line_number":102,"context_line":"  * \"baremetal.node.provision_set.end\""},{"line_number":103,"context_line":"  * \"baremetal.conductor.init.success\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_ce031d41","line":100,"updated":"2016-09-06 16:38:43.000000000","message":"I think this is interesting. Nova has compute.instance.power_off.start/end and compute.instance.power_on.state/end [1]\n\nI\u0027m not sure why they didn\u0027t go with .power_set.... Was it to make it easier to know what the event is, w/o looking at the payload info? What do you think?\n\n[1] https://wiki.openstack.org/wiki/SystemUsageData#compute.instance.power_off.start.2F.end","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"55d5617b6bb7b303b0c03d69afe57d173ae44457","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  A few examples of potential event_type strings:"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"  * \"baremetal.node.power_set.start\""},{"line_number":100,"context_line":"  * \"baremetal.node.power_set.end\""},{"line_number":101,"context_line":"  * \"baremetal.node.provision_set.start\""},{"line_number":102,"context_line":"  * \"baremetal.node.provision_set.end\""},{"line_number":103,"context_line":"  * \"baremetal.conductor.init.success\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_4f429d69","line":100,"in_reply_to":"9a89bdaa_ce031d41","updated":"2016-09-06 22:07:09.000000000","message":"IDK, I don\u0027t think it\u0027s any more difficult to parse the payload than it is to parse the event type. They\u0027ll both always be in the notification.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"7cd753efd6887ab61411d0b5bbd85cba8bd54eb1","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  * \"baremetal.node.provision_set.start\""},{"line_number":102,"context_line":"  * \"baremetal.node.provision_set.end\""},{"line_number":103,"context_line":"  * \"baremetal.conductor.init.success\""},{"line_number":104,"context_line":"  * \"baremetal.conductor.stop.success\""},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* payload will be a versioned object related to the notification topic. This"},{"line_number":107,"context_line":"  should include relevant information about the event being notified on. For"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa7ab95a_1ec35a58","line":104,"updated":"2016-09-01 21:39:45.000000000","message":"i guess this will be emitted just *before* the conductor stops? :)","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"55d5617b6bb7b303b0c03d69afe57d173ae44457","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  * \"baremetal.node.provision_set.start\""},{"line_number":102,"context_line":"  * \"baremetal.node.provision_set.end\""},{"line_number":103,"context_line":"  * \"baremetal.conductor.init.success\""},{"line_number":104,"context_line":"  * \"baremetal.conductor.stop.success\""},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* payload will be a versioned object related to the notification topic. This"},{"line_number":107,"context_line":"  should include relevant information about the event being notified on. For"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_2fc399ee","line":104,"in_reply_to":"fa7ab95a_1ec35a58","updated":"2016-09-06 22:07:09.000000000","message":"Right :)","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"7cd753efd6887ab61411d0b5bbd85cba8bd54eb1","unresolved":false,"context_lines":[{"line_number":310,"context_line":"  modify existing notifications"},{"line_number":311,"context_line":"* Document an example of what an emitted notification will look like"},{"line_number":312,"context_line":"* Documentation should be added for each notification indicating when it\u0027s"},{"line_number":313,"context_line":"  expected to be emitted"},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"References"},{"line_number":316,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa7ab95a_3e89fe26","line":313,"updated":"2016-09-01 21:39:45.000000000","message":"I am concerned about consistency. If an operator has to look at the documentation to see whether a notification starts at the API level or at the conductor level or ..., it will be very confusing. Maybe this is something that we will have to develop over time, but my concern there is that we can have a mess in our hands.","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":13295,"name":"Mario Villaplana","email":"mario.villaplana@gmail.com","username":"mariojv"},"change_message_id":"55d5617b6bb7b303b0c03d69afe57d173ae44457","unresolved":false,"context_lines":[{"line_number":310,"context_line":"  modify existing notifications"},{"line_number":311,"context_line":"* Document an example of what an emitted notification will look like"},{"line_number":312,"context_line":"* Documentation should be added for each notification indicating when it\u0027s"},{"line_number":313,"context_line":"  expected to be emitted"},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"References"},{"line_number":316,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9a89bdaa_cf04ed19","line":313,"in_reply_to":"fa7ab95a_3e89fe26","updated":"2016-09-06 22:07:09.000000000","message":"I don\u0027t think there\u0027s a good way to generalize this that encompasses initial use cases being discussed.\n\nIf we guarantee that each notification starts on the API layer, then that doesn\u0027t leave room for notifications for operations ironic performs automatically. If everything happens on the conductor layer, CRUD events would be harder to track.\n\nI\u0027m not super concerned about a mess occurring here, and if it does happen it\u0027ll be a controlled mess thanks to versioning, even if no one reads the docs.\n\nWhat would you think about re-evaluating this point once a couple notifications have actually been merged in?","commit_id":"3880fbb2f5fb374f5423ee1c61f04aec6e13b8c1"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5d5923383047430a670bdee0f6ed990cbfcb6007","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  Given the above information, event_type will end up as a string on the"},{"line_number":93,"context_line":"  message bus with the following format:"},{"line_number":94,"context_line":"  ``baremetal.\u003cobject\u003e.\u003caction\u003e.\u003cstatus\u003e``"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"  A few examples of potential event_type strings:"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a89bdaa_68172eee","line":94,"updated":"2016-09-13 09:10:37.000000000","message":"baremetal part of the event_type might not be necessary as every event has a publisher_id that can clarify where the event is coming from here it is coming from the baremetal service. But it is also not a big problem if you prefix every event_type with baremental.","commit_id":"c5c7d92e45052c3e8f560acaa9e2110d32ea1e11"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"229cce594bd8337ca27b0ff6aae0916ce0f7a10e","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  Given the above information, event_type will end up as a string on the"},{"line_number":93,"context_line":"  message bus with the following format:"},{"line_number":94,"context_line":"  ``baremetal.\u003cobject\u003e.\u003caction\u003e.\u003cstatus\u003e``"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"  A few examples of potential event_type strings:"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a8ec9b2_e4986e6d","line":94,"in_reply_to":"9a89bdaa_68172eee","updated":"2016-09-13 18:03:26.000000000","message":"That\u0027s a good point. Our publisher IDs won\u0027t have \u0027baremetal\u0027 in them; \u0027conductor\u0027 or \u0027api\u0027 I think (maybe better as ironic-conductor, ironic-api). But if, for whatever reason, someone is just looking at event_type strings, it wouldn\u0027t hurt to throw in the \u0027baremetal\u0027. Having spent some time recently on the openstackclient plugin for ironic, *everything* should be prefixed with \u0027baremetal\u0027 :D.","commit_id":"c5c7d92e45052c3e8f560acaa9e2110d32ea1e11"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"f3c2064a8985b8aacbedf87f1f0fb1ea3d4184a0","unresolved":false,"context_lines":[{"line_number":318,"context_line":".. [#] https://blueprints.launchpad.net/nova/+spec/notification-system"},{"line_number":319,"context_line":".. [#] http://docs.openstack.org/developer/oslo.messaging/notifier.html"},{"line_number":320,"context_line":".. [#] https://wiki.openstack.org/wiki/LoggingStandards#Log_level_definitions"},{"line_number":321,"context_line":".. [#] Nova versioned notifications spec: https://github.com/openstack/nova-specs/blob/master/specs/mitaka/approved/versioned-notification-api.rst"},{"line_number":322,"context_line":".. [#] http://docs.openstack.org/developer/oslo.messaging/opts.html"},{"line_number":323,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a89bdaa_8371b546","line":321,"updated":"2016-09-07 14:59:25.000000000","message":"if you do another revision, this link is bad. The final spec is available at http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/versioned-notification-api.html","commit_id":"c5c7d92e45052c3e8f560acaa9e2110d32ea1e11"}]}