)]}'
{"specs/liberty/hot-signals.rst":[{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"e3f10ea95556707d98a0e72dd4b8f31878604a7c","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"The standard way to signal a resource is to do it through a request to"},{"line_number":22,"context_line":"heat-api. This works well for user generated signals, but when the signals are"},{"line_number":23,"context_line":"generated internally as a result of an event, the user credentials are not"},{"line_number":24,"context_line":"available. Heat resources implement a variety of mechanisms to make signals"},{"line_number":25,"context_line":"work in this context."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_64195388","line":23,"updated":"2015-05-07 13:19:00.000000000","message":"\"internally as a result of an event\" makes me think of intra-engine signalling, e.g RPC, where credentials aren\u0027t a problem, because we either have them, or can load the stored context.\n\nReading further clarifies, but is there any way we can make this a bit clearer, perhaps something like:\n\n\"This works well for signals generated by human users, but for signals generated from either inside instances, or from other services, user credentials need to be made available\"\n\nOr something along those lines?","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"change_message_id":"b41fa4245907d3f81cb25924b89841430be3721c","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"The standard way to signal a resource is to do it through a request to"},{"line_number":22,"context_line":"heat-api. This works well for user generated signals, but when the signals are"},{"line_number":23,"context_line":"generated internally as a result of an event, the user credentials are not"},{"line_number":24,"context_line":"available. Heat resources implement a variety of mechanisms to make signals"},{"line_number":25,"context_line":"work in this context."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_b8ab081d","line":23,"in_reply_to":"1aca2d91_64195388","updated":"2015-05-07 14:40:35.000000000","message":"Yes, I think using \"event\" here is confusing, I\u0027ll change the wording to make it more clear.","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"e3f10ea95556707d98a0e72dd4b8f31878604a7c","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  process to trigger this signal involves requesting a keystone token, then"},{"line_number":75,"context_line":"  sending the signal request to heat-api with this token. The keystone"},{"line_number":76,"context_line":"  credentials necessary to obtain the token are given in the ``signal``"},{"line_number":77,"context_line":"  attribute."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_472ad97f","line":77,"updated":"2015-05-07 13:19:00.000000000","message":"It may be worth mentioning that for HEAT_SIGNAL, the credentials will be associated with the domain-isolated user associated with the resource, not the user who owns the stack?","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"change_message_id":"b41fa4245907d3f81cb25924b89841430be3721c","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  process to trigger this signal involves requesting a keystone token, then"},{"line_number":75,"context_line":"  sending the signal request to heat-api with this token. The keystone"},{"line_number":76,"context_line":"  credentials necessary to obtain the token are given in the ``signal``"},{"line_number":77,"context_line":"  attribute."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_b807881b","line":77,"in_reply_to":"1aca2d91_472ad97f","updated":"2015-05-07 14:40:35.000000000","message":"Okay, I\u0027ll make that clarification.","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"e3f10ea95556707d98a0e72dd4b8f31878604a7c","unresolved":false,"context_lines":[{"line_number":83,"context_line":"endpoint. This is a less flexible approach, and it has the drawback that the"},{"line_number":84,"context_line":"authentication tokens are embedded in URLs, which are typically written to"},{"line_number":85,"context_line":"logfiles. The nice thing about the proposed solution is that nothing prevents"},{"line_number":86,"context_line":"a webhook signal to be added to the list of signal options in the future."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Implementation"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_87e35133","line":86,"updated":"2015-05-07 13:19:00.000000000","message":"IMO this would be nice, but it should be a keystone feature, not a heat one - I know Swift implements it\u0027s own tempurl auth scheme, but IMHO services shouldn\u0027t be hand-rolling their own auth like that - it\u0027s be much better if there was a keystone-supported openstack wide way to solve this.\n\nFWIW I though OAuth was going to be that solution, when keystone added support for it, but on closer investigation it turned out there was still no (non-global) way to disable expiry of the signed requests, so it didn\u0027t solve our problem for a secret that can be deployed inside an instance.\n\nAlso, I know keystone is gaining support for certificate based auth schemes, so perhaps we can (in due course) see if that will help solve this problem.","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"change_message_id":"b41fa4245907d3f81cb25924b89841430be3721c","unresolved":false,"context_lines":[{"line_number":83,"context_line":"endpoint. This is a less flexible approach, and it has the drawback that the"},{"line_number":84,"context_line":"authentication tokens are embedded in URLs, which are typically written to"},{"line_number":85,"context_line":"logfiles. The nice thing about the proposed solution is that nothing prevents"},{"line_number":86,"context_line":"a webhook signal to be added to the list of signal options in the future."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Implementation"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aca2d91_13ce5fb4","line":86,"in_reply_to":"1aca2d91_87e35133","updated":"2015-05-07 14:40:35.000000000","message":"Agreed that this should be done by keystone, hopefully in a way that the keystone middleware can do the verification for us (including allowing these no-expiry tokens to only work on the specific endpoint it was created for and no others).","commit_id":"6cb27c8a017c5ff90dc02b65dbbb4b88f00e1375"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"62dd18dc471595b3aa2776108b44d818f9bfc106","unresolved":false,"context_lines":[{"line_number":7,"context_line":".."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":" HOT Signals"},{"line_number":11,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/heat/+spec/hot-signals"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aca2d91_5c785f2b","line":10,"updated":"2015-05-07 17:41:59.000000000","message":"It occurred to me that this actually doesn\u0027t have anything to do with HOT - e.g the DSL we use for the template - if you wanted to, the resources modified via this proposal could be deployed via CFN format json templates.\n\nMaybe this should just be called \"Unified Resource Signals\" or similar?","commit_id":"1f9a71ab799788e76a475130ab6336d06ae7fb84"},{"author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"change_message_id":"68040415bab5d45364d9cebabb214e3ee133c35e","unresolved":false,"context_lines":[{"line_number":7,"context_line":".."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":" HOT Signals"},{"line_number":11,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/heat/+spec/hot-signals"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aca2d91_a27f4e65","line":10,"in_reply_to":"1aca2d91_5c785f2b","updated":"2015-05-07 18:22:43.000000000","message":"Agreed. Main motivation is obviously to improve the situation for HOT, but there is nothing in here that will prevent these signals to be used in CFN templates. Thanks!","commit_id":"1f9a71ab799788e76a475130ab6336d06ae7fb84"}],"specs/liberty/uniform-resource-signals.rst":[{"author":{"_account_id":6899,"name":"Sirushti Murugesan","email":"sirushtim@gmail.com","username":"sirushtim"},"change_message_id":"12ca6608a3b67651a41e74ada729f0bdac3f6381","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  sending the signal request to heat-api with this token. The keystone"},{"line_number":78,"context_line":"  credentials necessary to obtain the token are given in the ``signal``"},{"line_number":79,"context_line":"  attribute. Note that these credentials are not the user\u0027s, but those of a"},{"line_number":80,"context_line":"  temporary user created by heat."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aca2d91_34c6ca48","line":80,"updated":"2015-05-08 04:06:04.000000000","message":"I suppose ZAQAR_SIGNAL could be another option?","commit_id":"8659d4206f1588f4e7630ae66d51a52a0b97176b"},{"author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"change_message_id":"7c5e2db18bfca455c11bb62d4f616a9bcee3a11e","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  sending the signal request to heat-api with this token. The keystone"},{"line_number":78,"context_line":"  credentials necessary to obtain the token are given in the ``signal``"},{"line_number":79,"context_line":"  attribute. Note that these credentials are not the user\u0027s, but those of a"},{"line_number":80,"context_line":"  temporary user created by heat."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aca2d91_c8837a55","line":80,"in_reply_to":"1aca2d91_34c6ca48","updated":"2015-05-08 04:53:33.000000000","message":"Sure, zaqar signaling could be implemented if there is interest.","commit_id":"8659d4206f1588f4e7630ae66d51a52a0b97176b"}]}