)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"03d1ec07a7b73960ddf14e1780ca5e0e163bfbbe","unresolved":false,"context_lines":[{"line_number":11,"context_line":"attempting to solve all the diagnostics use cases at once, the"},{"line_number":12,"context_line":"proposed implementation seeks to build-out the initial diagnostic"},{"line_number":13,"context_line":"plumbing as well as provide an initial reference implementation and"},{"line_number":14,"context_line":"suggested re-iterating on diagnostics once this concept has had"},{"line_number":15,"context_line":"some time to run in the wild."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"[1] https://wiki.openstack.org/wiki/Nova_VM_Diagnostics"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":7,"id":"9a629dbe_3a4ceb41","line":14,"range":{"start_line":14,"start_character":0,"end_line":14,"end_character":9},"updated":"2016-11-08 18:19:05.000000000","message":"Nit: suggests","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"}],"specs/newton/diagnostics.rst":[{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"-  *Troubleshooting* is a *process* that uses diagnostic information to"},{"line_number":55,"context_line":"   find the root cause (and potentially fix it). Troubleshooting"},{"line_number":56,"context_line":"   relates to a particular types of issues, e.g. \"cannot ping VM\u0027s"},{"line_number":57,"context_line":"   IP\" or \"DHCP address not being allocated\" that can be caused by"},{"line_number":58,"context_line":"   combination of bad configuration, resource failures etc. Thus it"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_0f743d9a","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":47},"updated":"2016-04-22 17:05:42.000000000","message":"Would it be more clear to just add another definition for \"remediation\" (e.g. action to fix) so that we can classify the 3 separately?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"-  *Troubleshooting* is a *process* that uses diagnostic information to"},{"line_number":55,"context_line":"   find the root cause (and potentially fix it). Troubleshooting"},{"line_number":56,"context_line":"   relates to a particular types of issues, e.g. \"cannot ping VM\u0027s"},{"line_number":57,"context_line":"   IP\" or \"DHCP address not being allocated\" that can be caused by"},{"line_number":58,"context_line":"   combination of bad configuration, resource failures etc. Thus it"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_9cffc000","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":47},"in_reply_to":"1a122d0e_0f743d9a","updated":"2016-04-25 12:38:21.000000000","message":"This spec covers diagnostics only. How would definition of remediation help here?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"68055d0286816a08f55602d021ca93bac87697cc","unresolved":false,"context_lines":[{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"-  *Troubleshooting* is a *process* that uses diagnostic information to"},{"line_number":55,"context_line":"   find the root cause (and potentially fix it). Troubleshooting"},{"line_number":56,"context_line":"   relates to a particular types of issues, e.g. \"cannot ping VM\u0027s"},{"line_number":57,"context_line":"   IP\" or \"DHCP address not being allocated\" that can be caused by"},{"line_number":58,"context_line":"   combination of bad configuration, resource failures etc. Thus it"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_34b1d347","line":55,"range":{"start_line":55,"start_character":24,"end_line":55,"end_character":47},"in_reply_to":"1a122d0e_9cffc000","updated":"2016-04-29 20:39:39.000000000","message":"The statement \"and potentially fix it\" leads to ambiguity IMHO. It\u0027s a nit. I would prefer to have a sentence here that said something like \"Remediation, the process of fixing a root caused problem, maybe included as part of troubleshooting or as a separate process\".\n\nAgain its a nit.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":94,"context_line":"----------------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_4f41150b","line":97,"range":{"start_line":97,"start_character":49,"end_line":97,"end_character":70},"updated":"2016-04-22 17:05:42.000000000","message":"Perhaps a ref/link to what exactly this is would be useful just to make sure we are all on the same page?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":94,"context_line":"----------------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_7c858457","line":97,"range":{"start_line":97,"start_character":49,"end_line":97,"end_character":70},"in_reply_to":"1a122d0e_4f41150b","updated":"2016-04-25 12:38:21.000000000","message":"Thanks, support for SUB_RESOURCES is meant. I\u0027ll add link to https://github.com/openstack/neutron/blob/stable/mitaka/neutron/api/v2/router.py#L114","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":102,"context_line":"   collection"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_95a33c9e","line":99,"range":{"start_line":99,"start_character":25,"end_line":99,"end_character":50},"updated":"2016-04-22 17:05:42.000000000","message":"Any additional RBAC considerations? For example can RBAC be enforced on a per check basis?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":102,"context_line":"   collection"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_dcf3f808","line":99,"range":{"start_line":99,"start_character":25,"end_line":99,"end_character":50},"in_reply_to":"1a122d0e_95a33c9e","updated":"2016-04-25 12:38:21.000000000","message":"Diagnostics is either accessible or not, no fine-grained ACLs at this moment.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"34c2d8f6434dfc08424ba8fbee6ed0abf6655bad","unresolved":false,"context_lines":[{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":102,"context_line":"   collection"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_0ddeae6c","line":99,"range":{"start_line":99,"start_character":25,"end_line":99,"end_character":50},"in_reply_to":"1a122d0e_b9de7c0e","updated":"2016-05-06 13:06:51.000000000","message":"It is admin-only as the checks can potentially reveal infrastructure details and no ACLs are currently expected that would only allow access to those checks that are \"safe\".","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"68055d0286816a08f55602d021ca93bac87697cc","unresolved":false,"context_lines":[{"line_number":96,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":97,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax)."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":102,"context_line":"   collection"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_b9de7c0e","line":99,"range":{"start_line":99,"start_character":25,"end_line":99,"end_character":50},"in_reply_to":"1a122d0e_dcf3f808","updated":"2016-04-29 20:39:39.000000000","message":"There was some discussion in regards to tenants being able to get diagnostics for resources they own/access. It\u0027s not clear to me if we are saying this is an admin-only API or if resource/collection RBAC policies apply at the health check level?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":107,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":108,"context_line":"generally different."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The checks is obtained dynamically upon initialization of the newly"},{"line_number":111,"context_line":"created diagnostic extension. The implemented checks should only be"},{"line_number":112,"context_line":"low-level checks that do not consist of other exposed checks (e.g. ping,"},{"line_number":113,"context_line":"is HA router’s keepalived process alive?, is given interface up and"},{"line_number":114,"context_line":"running?), and not high-level checks that aggregate results from other"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_efa3c1af","line":111,"range":{"start_line":110,"start_character":0,"end_line":111,"end_character":28},"updated":"2016-04-22 17:05:42.000000000","message":"I\u0027m a little confused by this sentence -- is it just saying the checks are pluggable and loaded at start-up? Maybe this could use a little clarity.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":108,"context_line":"generally different."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The checks is obtained dynamically upon initialization of the newly"},{"line_number":111,"context_line":"created diagnostic extension. The implemented checks should only be"},{"line_number":112,"context_line":"low-level checks that do not consist of other exposed checks (e.g. ping,"},{"line_number":113,"context_line":"is HA router’s keepalived process alive?, is given interface up and"},{"line_number":114,"context_line":"running?), and not high-level checks that aggregate results from other"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_0f8f1d24","line":111,"range":{"start_line":111,"start_character":34,"end_line":111,"end_character":67},"updated":"2016-04-22 17:05:42.000000000","message":"Technically this enforcement is just based on best judgement right? e.g. in reality one could write a check that does anything assuming they could get it through code review.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":108,"context_line":"generally different."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The checks is obtained dynamically upon initialization of the newly"},{"line_number":111,"context_line":"created diagnostic extension. The implemented checks should only be"},{"line_number":112,"context_line":"low-level checks that do not consist of other exposed checks (e.g. ping,"},{"line_number":113,"context_line":"is HA router’s keepalived process alive?, is given interface up and"},{"line_number":114,"context_line":"running?), and not high-level checks that aggregate results from other"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_177d4b1c","line":111,"range":{"start_line":111,"start_character":34,"end_line":111,"end_character":67},"in_reply_to":"1a122d0e_0f8f1d24","updated":"2016-04-25 12:38:21.000000000","message":"Almost yes. Technically, if there would be more than description of the state returned by the check, e.g. it would contain logic for aggregating results of some subchecks, it would violate this rule. A check should only return simple results like \"ok\", \"inactive device\", \"non-existent device\" etc. The logic for aggregation should stay away, e.g. in the troubleshooting tool.\n\nRationale: Troubleshooting can be seen by some only as a complex check. The point here is to keep troubleshooting outside neutron server code and to allow in only diagnostic checks, as maintainability of (still evolving) troubleshooting code becomes rather hard with time.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":107,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":108,"context_line":"generally different."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The checks is obtained dynamically upon initialization of the newly"},{"line_number":111,"context_line":"created diagnostic extension. The implemented checks should only be"},{"line_number":112,"context_line":"low-level checks that do not consist of other exposed checks (e.g. ping,"},{"line_number":113,"context_line":"is HA router’s keepalived process alive?, is given interface up and"},{"line_number":114,"context_line":"running?), and not high-level checks that aggregate results from other"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_772e3ffb","line":111,"range":{"start_line":110,"start_character":0,"end_line":111,"end_character":28},"in_reply_to":"1a122d0e_efa3c1af","updated":"2016-04-25 12:38:21.000000000","message":"Yes, if \"optional subsystem enabling execution of checks\" is meant by \"pluggable checks\". It also says that an extension will be added - that would control availability of the \"health\" diagnostic suburl.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":125,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":126,"context_line":"| Method   | Description                                                                |"},{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_af01c908","line":128,"range":{"start_line":128,"start_character":2,"end_line":128,"end_character":6},"updated":"2016-04-22 17:05:42.000000000","message":"How would consumers cope with changing check interfaces (e.g. v2 of check changes parameters or returns)? Is there some type of versioning needed?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":125,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":126,"context_line":"| Method   | Description                                                                |"},{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_6a683f22","line":128,"range":{"start_line":128,"start_character":2,"end_line":128,"end_character":6},"updated":"2016-04-22 17:05:42.000000000","message":"POST and not PUT? As per the API WG: https://github.com/openstack/api-wg/blob/master/guidelines/http.rst\n\n\"POST should be used when the URI of the resulting resource is different from the URI to which the request was made and results in the resource having an identifier (the URI) that the server generated\"\n\nSeems to imply PUT should be used in this case?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":125,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":126,"context_line":"| Method   | Description                                                                |"},{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_d282c1ff","line":128,"range":{"start_line":128,"start_character":2,"end_line":128,"end_character":6},"in_reply_to":"1a122d0e_6a683f22","updated":"2016-04-25 12:38:21.000000000","message":"GET would be most appropriate but GET should generally not contain body (excellent explanation as to why is in [1]). URI query parameters or encoding parameters in URI path elements would become cumbersome once complex parameters would need to be passed to the checks (e.g. arrays, hashes etc.) Body is hence required to pass in the parameters.\n\nThe same document [2] also mentions that \"[...] if the id of the resource being created is known, use PUT and PUT to the correct URI of the resource. Otherwise, use POST and POST to a more generic URI which will respond with the new URI of the resource.\" I believe that the latter applies here, hence I\u0027d stick to POST method.\n\n[1] http://stackoverflow.com/a/983458\n[2] https://github.com/openstack/api-wg/blob/master/guidelines/http.rst","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":125,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":126,"context_line":"| Method   | Description                                                                |"},{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_37f84749","line":128,"range":{"start_line":128,"start_character":2,"end_line":128,"end_character":6},"in_reply_to":"1a122d0e_af01c908","updated":"2016-04-25 12:38:21.000000000","message":"Versioning would be nice and I believe once microversioning would be sorted out generally for neutron API, it would be applicable to diagnostics as well.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"},{"line_number":132,"context_line":"|          | | {                                                                        |"},{"line_number":133,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_d59f745d","line":130,"range":{"start_line":130,"start_character":13,"end_line":130,"end_character":25},"updated":"2016-04-22 17:05:42.000000000","message":"A few question\u0027s here:\n(a) Are the checks executed in parallel or serially?\n(b) If serially, I assume there\u0027s no way to order the check execution since the checks are passed in a map?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":127,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":128,"context_line":"| POST     | Executes the named checks (check1, check2, ...), passing in parameters:    |"},{"line_number":129,"context_line":"|          |                                                                            |"},{"line_number":130,"context_line":"|          | Request body:                                                              |"},{"line_number":131,"context_line":"|          |                                                                            |"},{"line_number":132,"context_line":"|          | | {                                                                        |"},{"line_number":133,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_97bcbb6d","line":130,"range":{"start_line":130,"start_character":13,"end_line":130,"end_character":25},"in_reply_to":"1a122d0e_d59f745d","updated":"2016-04-25 12:38:21.000000000","message":"There will be no guarantee on the execution order of checks. Sequential execution can be achieved by submitting appropriate check requests in required order individually.\n\nAd (a), parallel execution would be the preferred way internally but not guaranteed.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":181,"context_line":"   /v2/subnets/**health**."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":184,"context_line":"   supported by a backend, an error is returned."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":187,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_aa2a578e","line":184,"range":{"start_line":184,"start_character":3,"end_line":184,"end_character":25},"updated":"2016-04-22 17:05:42.000000000","message":"Not all checks are associated with a \"backend\" though right? For example, the dhcp agent checks from PBAM are really tied to the DHCP agent, not a core plugin. Maybe this is just a wording (\"backend\") confusion on my part.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"34c2d8f6434dfc08424ba8fbee6ed0abf6655bad","unresolved":false,"context_lines":[{"line_number":181,"context_line":"   /v2/subnets/**health**."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":184,"context_line":"   supported by a backend, an error is returned."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":187,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_0de86ee1","line":184,"range":{"start_line":184,"start_character":3,"end_line":184,"end_character":25},"in_reply_to":"1a122d0e_59f5a84e","updated":"2016-05-06 13:06:51.000000000","message":"The checks are not generic here (though a plugin can impose requirement for its drivers to implement particular set of checks if needed), rather the dynamic. I\u0027ll rephrase the spec to clarify.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":181,"context_line":"   /v2/subnets/**health**."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":184,"context_line":"   supported by a backend, an error is returned."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":187,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_b20c653c","line":184,"range":{"start_line":184,"start_character":3,"end_line":184,"end_character":25},"in_reply_to":"1a122d0e_aa2a578e","updated":"2016-04-25 12:38:21.000000000","message":"By backend I meant any part implementing the body of the check.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"68055d0286816a08f55602d021ca93bac87697cc","unresolved":false,"context_lines":[{"line_number":181,"context_line":"   /v2/subnets/**health**."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":184,"context_line":"   supported by a backend, an error is returned."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":187,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_59f5a84e","line":184,"range":{"start_line":184,"start_character":3,"end_line":184,"end_character":25},"in_reply_to":"1a122d0e_b20c653c","updated":"2016-04-29 20:39:39.000000000","message":"What I\u0027m trying to understand is if checks are generic across all plugins/drivers or are exposed per implementation (dynamic).\n\nFor example suppose core plugin X wants to expose a check \u0027find_missing_uplink\u0027 which applies to router ports backed by a SDN backend the plugin interfaces with. This check only applies to routers when plugin X is used, but is likely not applicable when other core plugins are used.\n\nIs this supported as per the proposal herein?\n\nIMO we really need a dynamic means to expose checks so the above is a supported use case allowing plugins to derive additional value add for their consumers.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":"-  *Technical note:* It is possible that two different diagnostic checks"},{"line_number":190,"context_line":"   register themselves for the same name. In that case, an error"},{"line_number":191,"context_line":"   will be logged and check would not be available."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Changes in Neutron CLI"},{"line_number":194,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_afed49b9","line":191,"range":{"start_line":191,"start_character":22,"end_line":191,"end_character":50},"updated":"2016-04-22 17:05:42.000000000","message":"The check wouldn\u0027t be avail at all, or it would just be backed by the 1st registered check of that name?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":"-  *Technical note:* It is possible that two different diagnostic checks"},{"line_number":190,"context_line":"   register themselves for the same name. In that case, an error"},{"line_number":191,"context_line":"   will be logged and check would not be available."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Changes in Neutron CLI"},{"line_number":194,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_b78617d9","line":191,"range":{"start_line":191,"start_character":22,"end_line":191,"end_character":50},"in_reply_to":"1a122d0e_afed49b9","updated":"2016-04-25 12:38:21.000000000","message":"At all - the latter would open space for unexpected results.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":227,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":228,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":229,"context_line":"   of logic in agents to supply diagnostic information upon request,"},{"line_number":230,"context_line":"   and an implementation of a **ping** check."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"},{"line_number":233,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_6ad67fc4","line":230,"range":{"start_line":230,"start_character":7,"end_line":230,"end_character":44},"updated":"2016-04-22 17:05:42.000000000","message":"What\u0027s your vision for how checks will be implemented+added to neutron? Are these stevedore plugins or something?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":227,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":228,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":229,"context_line":"   of logic in agents to supply diagnostic information upon request,"},{"line_number":230,"context_line":"   and an implementation of a **ping** check."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"},{"line_number":233,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_adea48aa","line":230,"range":{"start_line":230,"start_character":7,"end_line":230,"end_character":44},"in_reply_to":"1a122d0e_6ad67fc4","updated":"2016-04-25 12:38:21.000000000","message":"Checks will be stateless classes, one class per check, containing both execution logic and description of themselves.\n\nPlugins will expose list of available checks into a check registry. Please note that generic plugins like ml2 need not implement any checks or can e.g. gather the list of available checks from drivers. The registry of the checks will be initialized on start, and API would consult the registry to execute the checks in appropriate context.\n\nBefore going any further into implementation details, I would like to finish the spec.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":232,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"},{"line_number":233,"context_line":"   diagnostics API."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"3. *Sample troubleshooting tool:* A sample troubleshooting tool will be"},{"line_number":236,"context_line":"   implemented outside neutron tree to illustrate how to use API to"},{"line_number":237,"context_line":"   perform a troubleshooting task. This application would be able to"},{"line_number":238,"context_line":"   use neutron-client module updated for diagnostics from previous"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_7591409a","line":235,"range":{"start_line":235,"start_character":36,"end_line":235,"end_character":63},"updated":"2016-04-22 17:05:42.000000000","message":"Assuming this spec or something similar is implemented, it seems like this could evolve into its own project as we\u0027d surely want to share/reuse troubleshooting code.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":232,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"},{"line_number":233,"context_line":"   diagnostics API."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"3. *Sample troubleshooting tool:* A sample troubleshooting tool will be"},{"line_number":236,"context_line":"   implemented outside neutron tree to illustrate how to use API to"},{"line_number":237,"context_line":"   perform a troubleshooting task. This application would be able to"},{"line_number":238,"context_line":"   use neutron-client module updated for diagnostics from previous"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_b75d777b","line":235,"range":{"start_line":235,"start_character":36,"end_line":235,"end_character":63},"in_reply_to":"1a122d0e_7591409a","updated":"2016-04-25 12:38:21.000000000","message":"Absolutely, it can e.g. evolve to a library.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"632dea241b79093a2e552c2a8e9ca29cdfa50108","unresolved":false,"context_lines":[{"line_number":241,"context_line":"Future work"},{"line_number":242,"context_line":"-----------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":245,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":246,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_cffc0541","line":245,"range":{"start_line":244,"start_character":59,"end_line":245,"end_character":35},"updated":"2016-04-22 17:05:42.000000000","message":"Without this how do consumers know what checks are available, their params, returns, etc.?? e.g. how do they discover checks?","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"68055d0286816a08f55602d021ca93bac87697cc","unresolved":false,"context_lines":[{"line_number":241,"context_line":"Future work"},{"line_number":242,"context_line":"-----------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":245,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":246,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_597ac8ba","line":245,"range":{"start_line":244,"start_character":59,"end_line":245,"end_character":35},"in_reply_to":"1a122d0e_1255594f","updated":"2016-04-29 20:39:39.000000000","message":"IMO we need some way to document checks for our consumers. If they are not discoverable (short-term), then I think we need some other plan like they are all doc\u0027d in which case it would be nice to point that out in this spec. Otherwise I\u0027m not seeing how we clearly communicate check functionality to consumers making this a potentially negative user experience.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"34c2d8f6434dfc08424ba8fbee6ed0abf6655bad","unresolved":false,"context_lines":[{"line_number":241,"context_line":"Future work"},{"line_number":242,"context_line":"-----------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":245,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":246,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_0da4eea3","line":245,"range":{"start_line":244,"start_character":59,"end_line":245,"end_character":35},"in_reply_to":"1a122d0e_597ac8ba","updated":"2016-05-06 13:06:51.000000000","message":"I agree, documentation of the available checks will be needed until they are made discoverable.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"c236b6ac336cdb877129356012e610d05e23c868","unresolved":false,"context_lines":[{"line_number":241,"context_line":"Future work"},{"line_number":242,"context_line":"-----------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":245,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":246,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_1255594f","line":245,"range":{"start_line":244,"start_character":59,"end_line":245,"end_character":35},"in_reply_to":"1a122d0e_cffc0541","updated":"2016-04-25 12:38:21.000000000","message":"At this moment, the checks would not be discoverable, following the same approach as the rest of API.\n\nMy preference would be to have the list of checks and individual check description available for a particular collection/resource directly in the corresponding .../health subroot using GET method.\n\nIf that would not be acceptable I think that the diagnostic extension could provide /v2.0/health-info (or similar) subtroot with the information on target resources/collections and checks that can be used on these.","commit_id":"b16ee47a59ae0ac6a97b57d38250353dc9282d5a"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":94,"context_line":"calls as per Alternative 1"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**Alternative 2:**  Illustrated in the Figure 2 below. The user"},{"line_number":97,"context_line":"or a troubleshooting tool would request health check of floating ip address"},{"line_number":98,"context_line":"based on ID of the floating IP. Server diagnostic API implementation would"},{"line_number":99,"context_line":"first determine the setup of the tested part of the network (steps 1.1 - 1.3)"},{"line_number":100,"context_line":"and then perform straightforward calls (steps 2 - 4) to obtain the same"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_f6c40c60","line":97,"range":{"start_line":97,"start_character":65,"end_line":97,"end_character":67},"updated":"2016-05-09 21:16:45.000000000","message":"IP","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":94,"context_line":"calls as per Alternative 1"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**Alternative 2:**  Illustrated in the Figure 2 below. The user"},{"line_number":97,"context_line":"or a troubleshooting tool would request health check of floating ip address"},{"line_number":98,"context_line":"based on ID of the floating IP. Server diagnostic API implementation would"},{"line_number":99,"context_line":"first determine the setup of the tested part of the network (steps 1.1 - 1.3)"},{"line_number":100,"context_line":"and then perform straightforward calls (steps 2 - 4) to obtain the same"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_be5520fb","line":97,"range":{"start_line":97,"start_character":65,"end_line":97,"end_character":67},"in_reply_to":"dab17558_f6c40c60","updated":"2016-05-10 11:29:49.000000000","message":"Done","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"In other words, the difference between the two alternatives is that"},{"line_number":110,"context_line":"Alternative 1 accompanied by troubleshooting tool supports everything"},{"line_number":111,"context_line":"what Alternative 2 does, and further it exposes the low-level checks."},{"line_number":112,"context_line":"The basic difference is that Alternative 1 places troubleshooting"},{"line_number":113,"context_line":"logic into client while Alternative 2 makes it part of the server."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_16a1d0a3","line":111,"range":{"start_line":111,"start_character":29,"end_line":111,"end_character":36},"updated":"2016-05-09 21:16:45.000000000","message":"futhermore","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"In other words, the difference between the two alternatives is that"},{"line_number":110,"context_line":"Alternative 1 accompanied by troubleshooting tool supports everything"},{"line_number":111,"context_line":"what Alternative 2 does, and further it exposes the low-level checks."},{"line_number":112,"context_line":"The basic difference is that Alternative 1 places troubleshooting"},{"line_number":113,"context_line":"logic into client while Alternative 2 makes it part of the server."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_76af7c94","line":111,"range":{"start_line":111,"start_character":0,"end_line":111,"end_character":4},"updated":"2016-05-09 21:16:45.000000000","message":"that","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"In other words, the difference between the two alternatives is that"},{"line_number":110,"context_line":"Alternative 1 accompanied by troubleshooting tool supports everything"},{"line_number":111,"context_line":"what Alternative 2 does, and further it exposes the low-level checks."},{"line_number":112,"context_line":"The basic difference is that Alternative 1 places troubleshooting"},{"line_number":113,"context_line":"logic into client while Alternative 2 makes it part of the server."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_1e19cc79","line":111,"range":{"start_line":111,"start_character":29,"end_line":111,"end_character":36},"in_reply_to":"dab17558_16a1d0a3","updated":"2016-05-10 11:29:49.000000000","message":"Done","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"In other words, the difference between the two alternatives is that"},{"line_number":110,"context_line":"Alternative 1 accompanied by troubleshooting tool supports everything"},{"line_number":111,"context_line":"what Alternative 2 does, and further it exposes the low-level checks."},{"line_number":112,"context_line":"The basic difference is that Alternative 1 places troubleshooting"},{"line_number":113,"context_line":"logic into client while Alternative 2 makes it part of the server."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_fe3cc8c9","line":111,"range":{"start_line":111,"start_character":0,"end_line":111,"end_character":4},"in_reply_to":"dab17558_76af7c94","updated":"2016-05-10 11:29:49.000000000","message":"Done","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":132,"context_line":"    reexecuting the whole check suite."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"*   Clear boundary between diagnostics and troubleshooting, from which it"},{"line_number":135,"context_line":"    follows lower cost for maintainability of the checks."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"*   Flexibility in adding custom checks. New checks can be implemented,"},{"line_number":138,"context_line":"    plugged into neutron and immediately used with any client that supports"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_d3691ac0","line":135,"range":{"start_line":135,"start_character":27,"end_line":135,"end_character":56},"updated":"2016-05-09 21:16:45.000000000","message":"The reality is this may also allow us to innovate more rapidly on the troubleshooting code as it probably won\u0027t live in the neutron repo (as we know it can take a while to get a patch into neutron).","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":132,"context_line":"    reexecuting the whole check suite."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"*   Clear boundary between diagnostics and troubleshooting, from which it"},{"line_number":135,"context_line":"    follows lower cost for maintainability of the checks."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"*   Flexibility in adding custom checks. New checks can be implemented,"},{"line_number":138,"context_line":"    plugged into neutron and immediately used with any client that supports"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_2f48d8cb","line":135,"range":{"start_line":135,"start_character":27,"end_line":135,"end_character":56},"in_reply_to":"dab17558_d3691ac0","updated":"2016-05-10 11:29:49.000000000","message":"I agree. There will be a sample in-tree troubleshooting tool but no troubleshooting tool (including the in-tree one) would be able to cover all possible failure scenarios. Hence a fair expectation here is that there will be different out-of-tree tools covering some scenarios better than others.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":134,"context_line":"*   Clear boundary between diagnostics and troubleshooting, from which it"},{"line_number":135,"context_line":"    follows lower cost for maintainability of the checks."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"*   Flexibility in adding custom checks. New checks can be implemented,"},{"line_number":138,"context_line":"    plugged into neutron and immediately used with any client that supports"},{"line_number":139,"context_line":"    running generic checks (see `Changes in Neutron CLI`_ below), and possibly"},{"line_number":140,"context_line":"    later incorporated into a troubleshooting tool."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_b392969d","line":137,"range":{"start_line":137,"start_character":4,"end_line":137,"end_character":39},"updated":"2016-05-09 21:16:45.000000000","message":"Although I know there are pros/cons to both approaches, IMHO custom checks will enable a greater set of use cases in this space.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":160,"context_line":"----------------------"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":163,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax via"},{"line_number":164,"context_line":"``SUB_RESOURCES`` field)."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":167,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_dc55a750","line":164,"range":{"start_line":163,"start_character":31,"end_line":164,"end_character":23},"updated":"2016-05-09 21:16:45.000000000","message":"Possibile to add a ref that describes this syntax?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":160,"context_line":"----------------------"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Existing API (v2) URL structure follows the template"},{"line_number":163,"context_line":"/v2/*collection*/*object\\_id* (plus allowing for parent objects syntax via"},{"line_number":164,"context_line":"``SUB_RESOURCES`` field)."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"We propose enhancing the API with two new subroots:"},{"line_number":167,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_c3248dc6","line":164,"range":{"start_line":163,"start_character":31,"end_line":164,"end_character":23},"in_reply_to":"dab17558_dc55a750","updated":"2016-05-10 11:29:49.000000000","message":"Yes, will be addressed in next spec iteration.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":181,"context_line":"about an issue with e.g. a namespace, a named process (\u0027dnsmasq\u0027) or"},{"line_number":182,"context_line":"a named device (\u0027qg-XYZ\u0027)."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The list of supported checks is obtained dynamically upon"},{"line_number":185,"context_line":"initialization of the newly created diagnostic extension in the following"},{"line_number":186,"context_line":"manner: A plugin determines list of available checks by querying available"},{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_f9e35d31","line":187,"range":{"start_line":184,"start_character":0,"end_line":187,"end_character":23},"updated":"2016-05-09 21:16:45.000000000","message":"I\u0027m a little confused here. Are we saying this \"heath plugin\" queries all plugins which implement a particular extension?\n\nMaybe this needs just a little clarification or rewording as its not clear me to \"what plugin\" and what exactly \"drivers\" are here.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":181,"context_line":"about an issue with e.g. a namespace, a named process (\u0027dnsmasq\u0027) or"},{"line_number":182,"context_line":"a named device (\u0027qg-XYZ\u0027)."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The list of supported checks is obtained dynamically upon"},{"line_number":185,"context_line":"initialization of the newly created diagnostic extension in the following"},{"line_number":186,"context_line":"manner: A plugin determines list of available checks by querying available"},{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_6f2e6044","line":187,"range":{"start_line":184,"start_character":0,"end_line":187,"end_character":23},"in_reply_to":"dab17558_f9e35d31","updated":"2016-05-10 11:29:49.000000000","message":"I will try to clarify a bit more in the next iteration. I was mostly referring to ML2 architecture. Before updating the spec, what was meant is:\n* Plugin \u003d core and service plugin\n* Driver \u003d e.g. mechanism driver in ML2","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":186,"context_line":"manner: A plugin determines list of available checks by querying available"},{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"The implemented checks should only be low-level checks that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_5906e9ce","line":189,"range":{"start_line":189,"start_character":10,"end_line":189,"end_character":50},"updated":"2016-05-09 21:16:45.000000000","message":"Again, I don\u0027t mean to dive too deep, just trying to wrap my head around this.\n\nSo checks can be bound to specific collections/resources, or if a check is defined it applies to all collections/resources.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":186,"context_line":"manner: A plugin determines list of available checks by querying available"},{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"The implemented checks should only be low-level checks that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_cf1f8c06","line":189,"range":{"start_line":189,"start_character":10,"end_line":189,"end_character":50},"in_reply_to":"dab17558_5906e9ce","updated":"2016-05-10 11:29:49.000000000","message":"Checks can only be bound to specific collections/resources. Will be more specific in the next spec iteration.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"The implemented checks should only be low-level checks that"},{"line_number":193,"context_line":"do not consist of other exposed checks (e.g. ping, is HA router\u0027s"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_b936f5e4","line":190,"range":{"start_line":190,"start_character":25,"end_line":190,"end_character":39},"updated":"2016-05-09 21:16:45.000000000","message":"Including service plugins right?\ne.g.\nI could develop an out-of-tree neutron service plugin that implements checks and then plug it into neutron at runtime as a service plugin?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":187,"context_line":"checks from its drivers. A plugin can define some checks to be mandatory"},{"line_number":188,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available). The"},{"line_number":189,"context_line":"resulting list of the checks used by the extension is retrieved as a union"},{"line_number":190,"context_line":"of available checks from active plugins."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"The implemented checks should only be low-level checks that"},{"line_number":193,"context_line":"do not consist of other exposed checks (e.g. ping, is HA router\u0027s"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_835d657b","line":190,"range":{"start_line":190,"start_character":25,"end_line":190,"end_character":39},"in_reply_to":"dab17558_b936f5e4","updated":"2016-05-10 11:29:49.000000000","message":"Yes, will be addressed in next spec iteration.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":219,"context_line":"|          | | {                                                                        |"},{"line_number":220,"context_line":"|          | |   \"check1\": {                                                            |"},{"line_number":221,"context_line":"|          | |     \"err\\_code\": numeric\\_code,                                          |"},{"line_number":222,"context_line":"|          | |     \"status\": text\\_status,                                              |"},{"line_number":223,"context_line":"|          | |     \"stdout\": \"\",                                                        |"},{"line_number":224,"context_line":"|          | |     \"stderr\": \"\",                                                        |"},{"line_number":225,"context_line":"|          | |     \"*result\\_field\\_1*\\ \": \"...\",                                       |"},{"line_number":226,"context_line":"|          | |     \"*result\\_field\\_2*\\ \": \"...\",                                       |"},{"line_number":227,"context_line":"|          | |     ...                                                                  |"},{"line_number":228,"context_line":"|          | |   },                                                                     |"},{"line_number":229,"context_line":"|          | |   \"check2\": { ... },                                                     |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_5ceff786","line":226,"range":{"start_line":222,"start_character":19,"end_line":226,"end_character":49},"updated":"2016-05-09 21:16:45.000000000","message":"Translation considerations for these response strings?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":219,"context_line":"|          | | {                                                                        |"},{"line_number":220,"context_line":"|          | |   \"check1\": {                                                            |"},{"line_number":221,"context_line":"|          | |     \"err\\_code\": numeric\\_code,                                          |"},{"line_number":222,"context_line":"|          | |     \"status\": text\\_status,                                              |"},{"line_number":223,"context_line":"|          | |     \"stdout\": \"\",                                                        |"},{"line_number":224,"context_line":"|          | |     \"stderr\": \"\",                                                        |"},{"line_number":225,"context_line":"|          | |     \"*result\\_field\\_1*\\ \": \"...\",                                       |"},{"line_number":226,"context_line":"|          | |     \"*result\\_field\\_2*\\ \": \"...\",                                       |"},{"line_number":227,"context_line":"|          | |     ...                                                                  |"},{"line_number":228,"context_line":"|          | |   },                                                                     |"},{"line_number":229,"context_line":"|          | |   \"check2\": { ... },                                                     |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_794c729e","line":226,"range":{"start_line":222,"start_character":19,"end_line":226,"end_character":49},"in_reply_to":"dab17558_5ceff786","updated":"2016-05-10 11:29:49.000000000","message":"Will be addressed in next spec iteration.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":264,"context_line":"   /v2/subnets/**health**."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":267,"context_line":"   supported by a backend (driver), an error is returned."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":270,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_3c2f93f7","line":267,"range":{"start_line":267,"start_character":27,"end_line":267,"end_character":33},"updated":"2016-05-09 21:16:45.000000000","message":"driver \u003d\u003d plugin?\nI thought we used the term plugin in neutron land?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":264,"context_line":"   /v2/subnets/**health**."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"-  Execution of a registered check is always attempted, and if not"},{"line_number":267,"context_line":"   supported by a backend (driver), an error is returned."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":270,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_d4d0c5f8","line":267,"range":{"start_line":267,"start_character":27,"end_line":267,"end_character":33},"in_reply_to":"dab17558_3c2f93f7","updated":"2016-05-10 11:29:49.000000000","message":"No, driver !\u003d plugin. A plugin usually delegates execution of the check to the driver and/or agent. The driver / agent might refuse executing the check, e.g. because of missing implementation due to unsuccessful upgrade of a particular host and subsequent discrepancy in versions.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":277,"context_line":"Changes in Neutron CLI"},{"line_number":278,"context_line":"----------------------"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"Set of neutron CLI commands would be enhanced with a **diagnose** verb"},{"line_number":281,"context_line":"per each resource. Depending on presence of resource ID, There will be"},{"line_number":282,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":283,"context_line":"resources, respectively:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_13af2282","line":280,"range":{"start_line":280,"start_character":15,"end_line":280,"end_character":45},"updated":"2016-05-09 21:16:45.000000000","message":"Newbie question -- do we need to make sure someone that works on the neutron client reviews this spec?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":317,"context_line":"   diagnostics API."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"3. *Sample troubleshooting tool:* A sample troubleshooting tool will be"},{"line_number":320,"context_line":"   implemented outside neutron tree to illustrate how to use API to"},{"line_number":321,"context_line":"   perform a troubleshooting task. This application would be able to"},{"line_number":322,"context_line":"   use neutron-client module updated for diagnostics from previous"},{"line_number":323,"context_line":"   step."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_dc276710","line":320,"range":{"start_line":320,"start_character":15,"end_line":320,"end_character":36},"updated":"2016-05-09 21:16:45.000000000","message":"But in an openstack hosted project?","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":317,"context_line":"   diagnostics API."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"3. *Sample troubleshooting tool:* A sample troubleshooting tool will be"},{"line_number":320,"context_line":"   implemented outside neutron tree to illustrate how to use API to"},{"line_number":321,"context_line":"   perform a troubleshooting task. This application would be able to"},{"line_number":322,"context_line":"   use neutron-client module updated for diagnostics from previous"},{"line_number":323,"context_line":"   step."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_b4338161","line":320,"range":{"start_line":320,"start_character":15,"end_line":320,"end_character":36},"in_reply_to":"dab17558_dc276710","updated":"2016-05-10 11:29:49.000000000","message":"Good catch, this should have been changed to in-tree to conform with consensus from Austin.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7cf5b5b1fb517c2801743418094e389ac0f2f62f","unresolved":false,"context_lines":[{"line_number":325,"context_line":"Future work"},{"line_number":326,"context_line":"-----------"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":329,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":330,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_b3fe1636","line":329,"range":{"start_line":328,"start_character":56,"end_line":329,"end_character":35},"updated":"2016-05-09 21:16:45.000000000","message":"I keep harping on this, I know, but I\u0027m looking for this spec to say something about how consumers will know what checks are available to them...\n\nIf the health extension is going to have a list of the checks from start-up time, is it worth considering just exposing the list of checks on collections/resource so consumers can at least get a list of check names? e.g. GET /v2/{collection}/health would return a list of health check names for the collection.\n\nIf even that is out of scope, I guess I\u0027m looking for this doc to saying something like \"Check authors should document their checks by using the doc impact tag on their patch sets\", or something along those lines.\n\nI\u0027m just envisioning the first user trying this out... They read about this cool new feature and go to try it, but using the CLI and API they have no idea what checks they can try. Maybe I\u0027m missing something here.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"4a0ee19ea4147b46749020df270d0107ceb30acf","unresolved":false,"context_lines":[{"line_number":325,"context_line":"Future work"},{"line_number":326,"context_line":"-----------"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":329,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":330,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"| {"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_cf678ce7","line":329,"range":{"start_line":328,"start_character":56,"end_line":329,"end_character":35},"in_reply_to":"dab17558_b3fe1636","updated":"2016-05-10 11:29:49.000000000","message":"I agree with you. It is also my intention to have the documentation as close to the code as possible so that the space for differences between documentation and implementation is minimized. Yet I think this can be addressed in a follow-up spec once the actual diagnostics is in tree.\nI\u0027ll add the reminder for check authors to request DocImpact into next spec iteration, thanks.","commit_id":"94e512c21b2e927aee9ce4cf23780209e90ac0d8"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":11,"context_line":"RFE: https://bugs.launchpad.net/neutron/+bug/1507499"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To enable operators to reduce manual work upon experiencing networking"},{"line_number":14,"context_line":"issue, and to fast pinpoint the cause of a failure, there is a need for"},{"line_number":15,"context_line":"neutron to provide real-time diagnostics of its resources. This way,"},{"line_number":16,"context_line":"current need for manual checks, often requiring root access, would be"},{"line_number":17,"context_line":"gradually replaced by API queries. Providing diagnostics options in"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_103486dc","line":14,"range":{"start_line":14,"start_character":14,"end_line":14,"end_character":18},"updated":"2016-05-12 16:31:16.000000000","message":"fast -\u003e quickly","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":16,"context_line":"current need for manual checks, often requiring root access, would be"},{"line_number":17,"context_line":"gradually replaced by API queries. Providing diagnostics options in"},{"line_number":18,"context_line":"neutron API would also open space for development of specialized tools"},{"line_number":19,"context_line":"that would solve particular type of issues, e.g. inability to ping VM’s"},{"line_number":20,"context_line":"interface."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"This blueprint describes generic API for diagnostics of real state of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_5073aeb4","line":19,"range":{"start_line":19,"start_character":28,"end_line":19,"end_character":32},"updated":"2016-05-12 16:31:16.000000000","message":"type -\u003e types","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Problem Description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"One of common questions seen at ask.openstack.org and mailing lists is"},{"line_number":31,"context_line":"\"Why cannot I ping my floating IP address?\". Usually, there are common"},{"line_number":32,"context_line":"steps in the diagnostics required to answer the question involving"},{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_5081ee4c","line":30,"range":{"start_line":30,"start_character":0,"end_line":30,"end_character":13},"updated":"2016-05-12 16:31:16.000000000","message":"One of _the_ common","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"One of common questions seen at ask.openstack.org and mailing lists is"},{"line_number":31,"context_line":"\"Why cannot I ping my floating IP address?\". Usually, there are common"},{"line_number":32,"context_line":"steps in the diagnostics required to answer the question involving"},{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_509a8ec6","line":31,"range":{"start_line":31,"start_character":1,"end_line":31,"end_character":13},"updated":"2016-05-12 16:31:16.000000000","message":"Needs to be \"Why can\u0027t I\" or \"Why can I not\"","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. It however provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little details of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_10be46ff","line":39,"range":{"start_line":39,"start_character":12,"end_line":39,"end_character":50},"updated":"2016-05-12 16:31:16.000000000","message":"-\u003e However, it provides very little","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":20277,"name":"James Anziano","email":"janzian@us.ibm.com","username":"janzian"},"change_message_id":"1744f51a235e1ab6925e10731087f6efd72f1c23","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. It however provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little details of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"},{"line_number":43,"context_line":"issue."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"This blueprint describes an extension of current API that exposes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_1003e6b9","line":42,"range":{"start_line":40,"start_character":48,"end_line":42,"end_character":8},"updated":"2016-05-12 16:31:16.000000000","message":"-\u003e Hence, if an issue occurs, user is often left with (\"little detail\" or \"few details\") as to what works and what doesn\u0027t","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"21384118b21cc1800f8e2b4080bb185041c6e715","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"If API proposed by this blueprint was available, it would be"},{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"},{"line_number":82,"context_line":"diagnostic information."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"**Alternative 1:**  Illustrated in the Figure 1 below. The user"},{"line_number":85,"context_line":"or a troubleshooting tool would first determine the setup of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dab17558_260d90e8","line":82,"updated":"2016-05-10 15:16:23.000000000","message":"Nit: Might flow nice to have a sentence explaining alt1 + 2 coming up. e.g. \"Two alternative approaches for implementing this API are given below.\"","commit_id":"d2b69061e66011617dbdcd560a322f5c682e7b8b"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"RFE: https://bugs.launchpad.net/neutron/+bug/1507499"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To enable operators to reduce manual work upon experiencing networking"},{"line_number":14,"context_line":"issue, and to quickly pinpoint the cause of a failure, there is a need for"},{"line_number":15,"context_line":"neutron to provide real-time diagnostics of its resources. This way,"},{"line_number":16,"context_line":"current need for manual checks, often requiring root access, would be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_fca98b7c","line":13,"updated":"2016-05-19 18:42:47.000000000","message":"even regular users, I\u0027d add, because there\u0027s certain things that a non privileged user can still do that does not require superuser access.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"RFE: https://bugs.launchpad.net/neutron/+bug/1507499"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To enable operators to reduce manual work upon experiencing networking"},{"line_number":14,"context_line":"issue, and to quickly pinpoint the cause of a failure, there is a need for"},{"line_number":15,"context_line":"neutron to provide real-time diagnostics of its resources. This way,"},{"line_number":16,"context_line":"current need for manual checks, often requiring root access, would be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_27f2249b","line":13,"in_reply_to":"bab6814e_fca98b7c","updated":"2016-06-09 20:58:45.000000000","message":"I think that this would have to be further explored with specific examples after we iterate further on the spec and some variables are eliminated.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"},{"line_number":35,"context_line":"often by crawling the relevant hosts and running tools that require root"},{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_bc2263ff","line":36,"updated":"2016-05-19 18:42:47.000000000","message":"we\u0027ve already crossed the implementation domain from the problem domain and spilled internal details when you mentioned namespaces. We should try and be as agnostic as we can be of technology backends.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"},{"line_number":35,"context_line":"often by crawling the relevant hosts and running tools that require root"},{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3791d753","line":36,"in_reply_to":"bab6814e_0c44fd47","updated":"2016-05-24 00:42:56.000000000","message":"I don\u0027t disagree that we need a level of in-depth information, but the more implementation details you expose the more tightly coupled and less agnostic the abstraction becomes in relation to the specific technology. Ideally the user should not perform any remediation action directly but the system can perform those on his/her behalf. In this case, most of the implementations can be omitted.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"},{"line_number":35,"context_line":"often by crawling the relevant hosts and running tools that require root"},{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b8d0f2f8","line":36,"in_reply_to":"bab6814e_3791d753","updated":"2016-05-24 19:15:33.000000000","message":"Point understood. I believe this can be delegated to the choice of the alternatives described below:\n\n* Alternative 1 gives more control of the diagnostic process to troubleshooting tool which means that specialized troubleshooting tools can be developed at the price of exposing environment details and coupling the used technology and troubleshooting tool (which can be also a good thing as it might allow for faster implementation of specialized troubleshooting tools).\n\n* Alternative 2 on the other hand enables for backend-agnostic checks and hides the implementation details into the implementation of plugins/drivers/agents at the price of maintaining not only checks but also actual troubleshooting code in neutron tree.\n\nFurther pros and cons of the alternatives are given from line  84 on.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"},{"line_number":35,"context_line":"often by crawling the relevant hosts and running tools that require root"},{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_a79e1405","line":36,"in_reply_to":"bab6814e_b8d0f2f8","updated":"2016-06-09 20:58:45.000000000","message":"@Armando, I understand your point, and the API and code design should be backend agnostic and allow for proper pluggability, but I think that the problem statement and descriptions early in the document must show examples to be useful, and using the reference implementation in those examples makes sense. It\u0027s not a complicated example anyway, it\u0027s easy to understand the intent and then to apply it to other backends. Part of the usefulness of the reference implementation is that it is a reference for other backends :)","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"},{"line_number":35,"context_line":"often by crawling the relevant hosts and running tools that require root"},{"line_number":36,"context_line":"access."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_0c44fd47","line":36,"in_reply_to":"bab6814e_bc2263ff","updated":"2016-05-23 12:02:46.000000000","message":"This is however exactly what the operators need when pinpointing the problem. Taking the namespace as an example, diagnostics needs to show to the operators that there is e.g. a missing namespace. If they only received information that \"Neutron cannot access interface\", they would be left in the same situation as without diagnostics. Hence the details of the underlying technology need to be exposed for diagnostics to be useful.\n\nThis blueprint provides unified, technology agnostic, solution in which the checks would be called in the same way and return format would also be always the same. It respects differences in actual setup though, these differences are encoded in which checks are called and what they do. Hence any neutron operator would be able to use them, and the results would respect the technologies of the diagnosed environment.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":70,"context_line":"assigned both fixed and floating IP address. Suppose now that the step"},{"line_number":71,"context_line":"of setting floating IP to the router has failed. Currently, user"},{"line_number":72,"context_line":"investigates the cause of the issue by logging to the host where port"},{"line_number":73,"context_line":"should have been created, finding out namespace in which the port was"},{"line_number":74,"context_line":"created, checking that the port is really there, attempt to ping"},{"line_number":75,"context_line":"relevant router, and once they find out this works, they have to log to"},{"line_number":76,"context_line":"(potentially different) host where the router resides, and finally find"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_ecdc8376","line":73,"updated":"2016-06-09 20:40:52.000000000","message":"The port in this case would not be created in a namespace.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":70,"context_line":"assigned both fixed and floating IP address. Suppose now that the step"},{"line_number":71,"context_line":"of setting floating IP to the router has failed. Currently, user"},{"line_number":72,"context_line":"investigates the cause of the issue by logging to the host where port"},{"line_number":73,"context_line":"should have been created, finding out namespace in which the port was"},{"line_number":74,"context_line":"created, checking that the port is really there, attempt to ping"},{"line_number":75,"context_line":"relevant router, and once they find out this works, they have to log to"},{"line_number":76,"context_line":"(potentially different) host where the router resides, and finally find"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_606241af","line":73,"in_reply_to":"7aa08908_ecdc8376","updated":"2016-06-10 11:03:21.000000000","message":"Thanks, it is the router namespace that needs to be determined later on in this example. Will be fixed in next iteration.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":75,"context_line":"relevant router, and once they find out this works, they have to log to"},{"line_number":76,"context_line":"(potentially different) host where the router resides, and finally find"},{"line_number":77,"context_line":"out that there is no interface in the router namespace that has"},{"line_number":78,"context_line":"respective floating IP assigned."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"If API proposed by this blueprint was available, it would be"},{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_fcf86b4b","line":78,"updated":"2016-05-19 18:42:47.000000000","message":"I am not sure this user story adds anything. You briefly mention this already and it is technology dependent, I\u0027d vote to remove it.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":75,"context_line":"relevant router, and once they find out this works, they have to log to"},{"line_number":76,"context_line":"(potentially different) host where the router resides, and finally find"},{"line_number":77,"context_line":"out that there is no interface in the router namespace that has"},{"line_number":78,"context_line":"respective floating IP assigned."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"If API proposed by this blueprint was available, it would be"},{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_45d97356","line":78,"in_reply_to":"bab6814e_fcf86b4b","updated":"2016-05-23 12:02:46.000000000","message":"This story is here in this detail to allow for elaborating on the two alternatives for automation further in the text. It is technology dependent for illustrative purposes.\n\nI don\u0027t mind removing it once an alternative would be agreed.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"},{"line_number":82,"context_line":"diagnostic information."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Two alternative approaches for implementing this API are given below."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"**Alternative 1:**  Illustrated in the Figure 1 below. The user"},{"line_number":87,"context_line":"or a troubleshooting tool would first determine the setup of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_1c83af99","line":84,"updated":"2016-05-19 18:42:47.000000000","message":"I don\u0027t believe we want to expose a \u0027ping\u0027 action to the user. The ping action should be hidden and may be something that is executed to determine the reachability status of a resource. A resource may be reachable or not and how this is done is through ping or whatever else the underlying platform choose to.\n\nSo in a nutshell, I think that both alternatives need refinement.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"},{"line_number":82,"context_line":"diagnostic information."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Two alternative approaches for implementing this API are given below."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"**Alternative 1:**  Illustrated in the Figure 1 below. The user"},{"line_number":87,"context_line":"or a troubleshooting tool would first determine the setup of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_51d93956","line":84,"in_reply_to":"bab6814e_1c83af99","updated":"2016-05-23 12:02:46.000000000","message":"If ping would not be exposed to the user, how would operator/user formulate and resolve the \"cannot _ping_ my VM floating IP address\" type of issue?\n\nFor instance, if missing security group rule is the issue, everything might be setup correctly from perspective of all neutron health checks validating individual resources. Port as well as network and floating IP would be \"healthy\". In such a situation, the information on which of the network segments is blocking the ping is at least helpful. Without simple \u0027ping\u0027 action, the user is left with the almost same situation as without diagnostics - everything seems to be correctly set up individually but the the components do not work together.\n\nHence a health check is necessary that checks whether port/floating IP is reachable from another port (within Neutron managed resources). Indeed it can be renamed from \"ping\" to e.g. \"reach\" but the technical reasoning remains unchanged.\n\nFor that matter, even though I incline to have check named \u0027ping\u0027 because that easy to understand for users/operators and thus contributing user experience, I am open to suggestions on the reachability check name.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"},{"line_number":82,"context_line":"diagnostic information."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Two alternative approaches for implementing this API are given below."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"**Alternative 1:**  Illustrated in the Figure 1 below. The user"},{"line_number":87,"context_line":"or a troubleshooting tool would first determine the setup of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_babdaed9","line":84,"in_reply_to":"bab6814e_51d93956","updated":"2016-05-24 00:42:56.000000000","message":"I agree that ping is such a basic and well known instrument to establish reachability to a given point. I am not suggesting not to use it. All I am suggesting is that the reachability check (whether performed via ping or not) is embedded in the reachability test procedure and only the outcome is exposed to the user, e.g. the reachability test is failed.\n\nIf a user is concerned with connectivity of a floating IP there are multiple reachability tests that must be performed along all the segments that make up the path to get to the destination (like you show in figure 2), I don\u0027t believe the user should proactively perform the tests himself/herself, or exposed to the underlying results. So between 2 and 1 I definitely like 2 more, but I\u0027d like to try and abstract the underlying details as much as we can. Approach 1 tightly couple the backend implementation to the troubleshooting tool","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":81,"context_line":"possible to automate some parts of the troubleshooting, namely obtaining the"},{"line_number":82,"context_line":"diagnostic information."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Two alternative approaches for implementing this API are given below."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"**Alternative 1:**  Illustrated in the Figure 1 below. The user"},{"line_number":87,"context_line":"or a troubleshooting tool would first determine the setup of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_92306609","line":84,"in_reply_to":"bab6814e_babdaed9","updated":"2016-05-24 19:15:33.000000000","message":"Reachability procedure, as an example of a troubleshooting scenario, is composed of elementary checks. While for users, aggregation of the results into a simpler description (works/does not work) might suffice, details of these health check results might be valuable to the operators, as the cause might be sitting outside neutron reach (e.g. faulty port in hardware switch).\n\nIt might be beneficial to aggregate results if the check is executed by ordinary user and show the details if the check is executed by operator. What do you think?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    checks differently and can approach specialized scenarios diagnostics"},{"line_number":126,"context_line":"    better than all-in-one solution."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"*   Tools can support more than one failure scenario per resource (e.g."},{"line_number":129,"context_line":"    two scenarios for a port: \"cannot ping provider network from this port\""},{"line_number":130,"context_line":"    and \"cannot ping to this port from outside\")"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_6cb533cf","line":128,"updated":"2016-06-09 20:40:52.000000000","message":"This is interesting. The first alternative lets the user express intent, while the second will have to guess it in certain scenarios. Can you come up with more scenarios that would express the point better?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":133,"context_line":"    check) has been resolved by executing a known named check, without"},{"line_number":134,"context_line":"    reexecuting the whole check suite."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"*   Clear boundary between diagnostics and troubleshooting, from which it"},{"line_number":137,"context_line":"    follows lower cost for maintainability of the checks."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"*   Flexibility in adding custom checks. New checks can be implemented,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_4c8cb735","line":136,"updated":"2016-06-09 20:40:52.000000000","message":"I disagree with this statement. There is nothing about alternative 2 that would imply that the code would be less maintainable.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":133,"context_line":"    check) has been resolved by executing a known named check, without"},{"line_number":134,"context_line":"    reexecuting the whole check suite."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"*   Clear boundary between diagnostics and troubleshooting, from which it"},{"line_number":137,"context_line":"    follows lower cost for maintainability of the checks."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"*   Flexibility in adding custom checks. New checks can be implemented,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_003ffd25","line":136,"in_reply_to":"7aa08908_4c8cb735","updated":"2016-06-10 11:03:21.000000000","message":"Alternative 1 requires only the elementary checks to be implemented and maintained in neutron server code. Alternative 2 requires implementation of both the elementary checks and troubleshooting checks (check aggregations representing failure scenarios) in neutron. \n\nElementary checks are straightforward probes, comparing what is expected to what is really observed and reporting the result. The aggregation checks are the ones that can become rather complex due to potential conditional execution of more detailed checks, depending on outcome of previous checks.\n\nThe difference in maintainability thus comes from the fact that Alternative 1 requires maintenance of smaller number of checks that are less complex, leaving the maintenance of troubleshooting checks to the troubleshooting tools.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    running generic checks (see `Changes in Neutron CLI`_ below), and possibly"},{"line_number":142,"context_line":"    later incorporated into a troubleshooting tool."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Benefits of Alternative 2 are:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"*   Simplicity in API as there is no check other than the predefined one"},{"line_number":147,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_ccca676e","line":144,"updated":"2016-06-09 20:40:52.000000000","message":"The main benefit of alternative 2 is that the solution would include patches to the openstack client that would expose health checks on resources, while alternative 1 dumps that responsibility on dedicated tools. The end result is when this spec is finished and implemented, alternative 2 comes \"batteries included\", while alternative 1 would require further changes to be immediately useful. This isn\u0027t mentioned here or in the text before it. It is mentioned that both alternatives are \"battery included\" in the work items section at the bottom of the spec, but the text up until this point leads the reader to believe that alternative 1 assumes that the troubleshooting part will be implemented later, possibly by other people in other projects.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    running generic checks (see `Changes in Neutron CLI`_ below), and possibly"},{"line_number":142,"context_line":"    later incorporated into a troubleshooting tool."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Benefits of Alternative 2 are:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"*   Simplicity in API as there is no check other than the predefined one"},{"line_number":147,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_f6e6fb14","line":144,"in_reply_to":"7aa08908_ccca676e","updated":"2016-06-10 11:03:21.000000000","message":"Tiny clarification - Alternative 2 is about placing the troubleshooting health checks into code of neutron server, not client. From perspective of Alternative 1, openstack client would be just another \"tool\" that can be enhanced with troubleshooting capabilities, that is to expose a troubleshooting check that would be implemented in the client by calling elementary checks on server. To the end user, this would be indeed transparent. From that perspective, even Alternative 1 would come \"batteries included\" provided there will be an implementation of a \"reachability test\" included.\n\nFurthermore, Alternative 1 would also be immediately useful to operators as it would allow them to use exposed elementary checks from a openstack client, removing the need to determine the affected host, log in there, and remotely execute respective shell commands. New checks would be also available in neutron server sooner for use as in Alternative 2, apart from the elementary check implementation that is common to both alternatives, a new check needs to be incorporated into troubleshooting (aggregation check) before it can be used.\n\nAnd to address the last sentence, yes, Alternative 1 assumes that there would be _also_ other people and other projects that would maintain their troubleshooting tools that would cover either new scenarios or existing scenarios in other ways than would already be available.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":153,"context_line":"proposed change below discusses Alternative 1 in full detail. Alternative 2"},{"line_number":154,"context_line":"can be obtained by allowing execution of a single check only (in Neutron API)"},{"line_number":155,"context_line":"and making this check to be *the* diagnostic check for a particular"},{"line_number":156,"context_line":"resource/collection."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Proposed Change"},{"line_number":159,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5f008901","line":156,"updated":"2016-05-19 18:42:47.000000000","message":"I personally find this paragraph rather confusing, especially when you mention in line 63 that troubleshooting is out of scope. My suggestion is to come up with the proposed change only to describe alternatives afterwards.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":153,"context_line":"proposed change below discusses Alternative 1 in full detail. Alternative 2"},{"line_number":154,"context_line":"can be obtained by allowing execution of a single check only (in Neutron API)"},{"line_number":155,"context_line":"and making this check to be *the* diagnostic check for a particular"},{"line_number":156,"context_line":"resource/collection."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Proposed Change"},{"line_number":159,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_80ad099d","line":156,"in_reply_to":"bab6814e_5f008901","updated":"2016-05-23 12:02:46.000000000","message":"Thanks for this point, I will rephrase that to get it into more consistent state.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":172,"context_line":"   collection"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":175,"context_line":"   resource"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":178,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_1f4d616c","line":175,"updated":"2016-05-19 18:42:47.000000000","message":"it would be nice to accompany this with practical examples eg.\n\n/v2/networks/foo_id/health","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":172,"context_line":"   collection"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":175,"context_line":"   resource"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":178,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_a0c92dae","line":175,"in_reply_to":"bab6814e_1f4d616c","updated":"2016-05-23 12:02:46.000000000","message":"Examples are included at the end of this blueprint. I will move some of them here or refer the respective subsection from this place.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":183,"context_line":"case of service plugins) or using dynamic lookup for checks (e.g. via"},{"line_number":184,"context_line":"stevedore). A plugin can define some checks to be mandatory"},{"line_number":185,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available)"},{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3f866565","line":186,"updated":"2016-05-19 18:42:47.000000000","message":"refuse to start? The tools and capabilities to assess the health of a system during its online operation rather than its bootstrap phase are different and I think they should stay as such.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":183,"context_line":"case of service plugins) or using dynamic lookup for checks (e.g. via"},{"line_number":184,"context_line":"stevedore). A plugin can define some checks to be mandatory"},{"line_number":185,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available)"},{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_fd8d9731","line":186,"in_reply_to":"bab6814e_3f866565","updated":"2016-05-23 12:02:46.000000000","message":"I can remove it. Reason for refusing to start is that once there is an issue with networking, and furthermore neutron would show error doing diagnostics, it could possibly annoy users more than plain refusal to start in the very beginning.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":183,"context_line":"case of service plugins) or using dynamic lookup for checks (e.g. via"},{"line_number":184,"context_line":"stevedore). A plugin can define some checks to be mandatory"},{"line_number":185,"context_line":"(this might be useful to ensure that e.g. \"ping\" is always available)"},{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_39252cae","line":186,"in_reply_to":"bab6814e_fd8d9731","updated":"2016-06-09 20:58:45.000000000","message":"I think that the neutron-server process should start without networking, RPC or DB access, and continuously try to reconnect. This allows for a simpler HA architecture. A *misconfiguration*, which as I understand it is not what you\u0027re referring to, should fail-early and disallow the server to start, but that\u0027s a different case.\n\n*Users* would not know the difference between a running neutron-server process with no API reachability, and a dead neutron-server *due* to lack of API reachability anyway.\n\nI don\u0027t see a need to define specific checks as optional or mandatory with either alternative (1 or 2) FWIW. The server exposes an API, and anything not exposed returns 404.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."},{"line_number":190,"context_line":"Please note that each check defines its target collection/resource,"},{"line_number":191,"context_line":"hence the union is not based on check name but both its target and"},{"line_number":192,"context_line":"name."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5fbb69e5","line":189,"updated":"2016-05-19 18:42:47.000000000","message":"If you intend to expose a health status to resources, and such attributes is a collection of multiple conditions, then I don\u0027t believe that the checks should be tied to plugins. My suggestion would be to have a practical example in mind, eg. port.\n\nWhat do you see are the conditions that make up the overall health of a port? What about a floating ip? What about a subnet? We should try and simplify the problem and focus on practical things we can do to improve visibility in the state of the afore mentioned Neutron resources; up until now you\u0027re still talking in rather generic terms.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."},{"line_number":190,"context_line":"Please note that each check defines its target collection/resource,"},{"line_number":191,"context_line":"hence the union is not based on check name but both its target and"},{"line_number":192,"context_line":"name."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_98d24733","line":189,"in_reply_to":"bab6814e_3a789e2b","updated":"2016-05-24 19:15:33.000000000","message":"I think that every implementation would define health of a resource (e.g. port) in terms of generally different health checks, even though some checks will be the same or very similar. Thus providing a framework that enables easy exposition of the health checks (Alt.1) or easy putting these checks together (Alt.2) would actually serve the purpose well, abstracting from what exactly health of a particular type of resource (e.g. port) means in particular implementation.\nNeutron would provide reference implementation of the health checks that concern port health, reachability between two ports etc. for e.g. ML2+OVS. This might be done once this framework gets in place. The other implementations would the follow similar pattern, some implementing less checks than the others.\nRegarding this particular blueprint, the expected outcome is expressed at the end in the Implementation phases section. The work on enhancing the diagnostics would then continue to cover further troublesome scenarios - but that would be kind of never ending work due to reasons I tried to summarize in my previous reply to this line.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."},{"line_number":190,"context_line":"Please note that each check defines its target collection/resource,"},{"line_number":191,"context_line":"hence the union is not based on check name but both its target and"},{"line_number":192,"context_line":"name."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3a789e2b","line":189,"in_reply_to":"bab6814e_5d11435c","updated":"2016-05-24 00:42:56.000000000","message":"My concern is what exactly to intend to implement in the context of this effort. If it\u0027s a general framework to expose troubleshooting information, that in itself will need to be decoupled on how you intend to use the framework for the Neutron\u0027s implementation of your choice, for modeling health of resources etc. I see most of these concepts intermingled together in this spec so far and I would like to see more clarity so that we can better assess when this efforts starts and finishes.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":186,"context_line":"and refuse to start if that check is not available."},{"line_number":187,"context_line":"The final list of the checks used by a newly developed API extension"},{"line_number":188,"context_line":"that would actually expose the **health** subroot is retrieved as"},{"line_number":189,"context_line":"a union of available checks from all active plugins."},{"line_number":190,"context_line":"Please note that each check defines its target collection/resource,"},{"line_number":191,"context_line":"hence the union is not based on check name but both its target and"},{"line_number":192,"context_line":"name."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5d11435c","line":189,"in_reply_to":"bab6814e_5fbb69e5","updated":"2016-05-23 12:02:46.000000000","message":"Yes, that is plenty of good questions on troubleshooting. I don\u0027t think there is easy answer to any of them and actually it will need gradual development. Why? Because the technologies are progressing fast and hence the number of issues that can go wrong grows with time.\n\nFor example, for port, there are considerations on which particular technology is meant? Open vSwitch? Linux Bridges? Is it ML2 at all? For each of them, the answer would be slightly different.\n\nThis blueprint attempts to build strong basis to ease exactly this task - troubleshooting in still-evolving environments - so that it would be easy to extend any plugin and driver with health checks, and hence support for quick development of new health checks for various scenarios and technologies.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":201,"context_line":"configuration. This reflects the way of troubleshooting similar to what"},{"line_number":202,"context_line":"operators do."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"Access to API is currently intended to be restricted to admin users only."},{"line_number":205,"context_line":"RBAC support for finer diagnostics access control can be discussed"},{"line_number":206,"context_line":"in a follow-up RFE. Reason is that some of the diagnostic information"},{"line_number":207,"context_line":"can reveal physical infrastructure details, by returning a message"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3fbae5c0","line":204,"updated":"2016-05-19 18:42:47.000000000","message":"I think we can have two levels of introspection, I can see that some health conditions are reasonable to be exposed to superusers, but others seem like they can be useful to low priv ones too.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":201,"context_line":"configuration. This reflects the way of troubleshooting similar to what"},{"line_number":202,"context_line":"operators do."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"Access to API is currently intended to be restricted to admin users only."},{"line_number":205,"context_line":"RBAC support for finer diagnostics access control can be discussed"},{"line_number":206,"context_line":"in a follow-up RFE. Reason is that some of the diagnostic information"},{"line_number":207,"context_line":"can reveal physical infrastructure details, by returning a message"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_36c0e34f","line":204,"in_reply_to":"bab6814e_3fbae5c0","updated":"2016-05-23 12:02:46.000000000","message":"This can be accomplished, e.g. by having per-check setting of required access level (e.g. superuser-only, user-permitted). Hence /health would be accessible to anyone, the access control validation would be done on check execution level.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":223,"context_line":"|          |                                                                            |"},{"line_number":224,"context_line":"|          | | {                                                                        |"},{"line_number":225,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"},{"line_number":226,"context_line":"|          | |  \"check2\": { r1: value1, r2: value2, ... },                              |"},{"line_number":227,"context_line":"|          | |  ...                                                                     |"},{"line_number":228,"context_line":"|          | | }                                                                        |"},{"line_number":229,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5f640921","line":226,"updated":"2016-05-19 18:42:47.000000000","message":"I don\u0027t agree that the checks should be user submitted. I think a request should be as simple as:\n\n neutron port-health-show port-uuid\n# alternatively\n neutron health-show --resource-type port --uuid port-uuid\n\nThat returns a summary of the health for the resource. A health is a composite property, and each attribute can be status condition that in itself should be characterized with a mnemonic label, an error code, a human readable description, and perhaps \u0027details\u0027, that can embed any further information that can assist the user to identify the erroneous condition and potentially the remedy action. Not all status conditions require the invocation of shell commands, thus I think it would be problematic to expose stdout/err. Adding custom result fields seem overkill.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":223,"context_line":"|          |                                                                            |"},{"line_number":224,"context_line":"|          | | {                                                                        |"},{"line_number":225,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"},{"line_number":226,"context_line":"|          | |  \"check2\": { r1: value1, r2: value2, ... },                              |"},{"line_number":227,"context_line":"|          | |  ...                                                                     |"},{"line_number":228,"context_line":"|          | | }                                                                        |"},{"line_number":229,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b03aed96","line":226,"in_reply_to":"bab6814e_5b66722a","updated":"2016-05-24 00:42:56.000000000","message":"For inter-port connectivity you can simply provide a mechanism for exposing health info of a combined resource, e.g /ports/foo/health?port_id\u003dbar.\n\nExposing raw stdout/stderr over the wire without sanitization would potentially expose too many details/security sensitive information to the user. It seems to me that we\u0027d be better off not opening that box during the first iteration of this effort.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":223,"context_line":"|          |                                                                            |"},{"line_number":224,"context_line":"|          | | {                                                                        |"},{"line_number":225,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"},{"line_number":226,"context_line":"|          | |  \"check2\": { r1: value1, r2: value2, ... },                              |"},{"line_number":227,"context_line":"|          | |  ...                                                                     |"},{"line_number":228,"context_line":"|          | | }                                                                        |"},{"line_number":229,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5b66722a","line":226,"in_reply_to":"bab6814e_5f640921","updated":"2016-05-23 12:02:46.000000000","message":"I think it cannot be that simple for some checks require additional parameters: e.g. the reachability check needs a port/IP to check with.\n\nIt seems that we are on the same page regarding the result: also this spec views health status as a composite property where individual checks (that are selected by the user/troubleshooting tool) return error code, description and details.\n\nWhere we differ is that details should be placed into \"details\" field (according to your suggestion) or structured into attributes in the returned result. This can be overcome by placing the structured result fields into details property, e.g.:\n\n { \"check1\": {\n   \"err_code\": numeric_code,\n   \"description\": desc,\n   \"status\": text_status,\n   \"details\": {\n     \"stdout\": \"...\",\n     \"stderr\": \"...\",\n     \"result_field_1*\": \"...\", ...\n   }\n }, ... }\n\nCould you please elaborate should exposing stdout/stderr be problematic? This would only apply to process-oriented checks, these fields are hence optional. On the other hand, having these outputs at hand might contribute to speed of resolving the issue.\n\nSimilarly, why would allowing for check-specialized result fields be overkill? If the check can provide useful outputs for troubleshooting tool apart from status code, why should it be forbidden?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":223,"context_line":"|          |                                                                            |"},{"line_number":224,"context_line":"|          | | {                                                                        |"},{"line_number":225,"context_line":"|          | |  \"check1\": { p1: value1, p2: value2, ... },                              |"},{"line_number":226,"context_line":"|          | |  \"check2\": { r1: value1, r2: value2, ... },                              |"},{"line_number":227,"context_line":"|          | |  ...                                                                     |"},{"line_number":228,"context_line":"|          | | }                                                                        |"},{"line_number":229,"context_line":"|          |                                                                            |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_573d6cba","line":226,"in_reply_to":"bab6814e_b03aed96","updated":"2016-05-24 19:15:33.000000000","message":"For discussion on combined resources, please see below.\n\nRe stdout/stderr: I understand the concerns and the original intent was to allow only operators to execute the checks exactly for this reason. I agree that if the ordinary users should be able to execute the checks too, sensitive information could be given away here. Hence I will omit these fields from the first iteration.\n\n\nAd combined resources: \n\n\nSo far there have been the following distinct cases of port health procedures mentioned in the comments:\n\n1. /ports/{id}/health\n2. /ports/{id}/health with parameter port_id\u003dX\n3. /ports/{id}/health with parameter floating_ip_id\u003dY\n\nEach of the checks tests a different scenario:\n\n1. Tests whether a particular port {id} interface exists,  is up etc.\n2. Tests reachability of a port X from port {id}\n3. Tests reachability of a floating IP from port {id}\n\nThere are two options to handle these:\n\n* (a) Depending on the given parameters, the health \"controller\" executes only those checks that are fully parameterized by given parameters\n* (b) Assign each scenario a name and request the user to specify which check they want to run by specifying the check name along with all parameters requested by the check.\n\nThe options lead to the following tests:\n\n* (a) Means that 2 always tests everything what 1 does, and similarly 3 always tests everything what 1 does, because 1 needs no parameters and would be hence executed always\n* (b) Means that 1, 2, and 3 test only the chosen scenarios.\n\nI prefer option (b) for there is clear predictability on which scenario is tested and hence which parameters are necessary to put in. It has also benefit of preventing execution of unnecessary checks (those that do not need parameters or can run with a proper subset of the given parameters).\n\nWhat do you think?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":263,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"If the check does not exist, the server responds with HTTP error 404"},{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_1f83a199","line":266,"updated":"2016-05-19 18:42:47.000000000","message":"I think this level of granularity is too much","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":263,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"If the check does not exist, the server responds with HTTP error 404"},{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_f6c2db51","line":266,"in_reply_to":"bab6814e_1f83a199","updated":"2016-05-23 12:02:46.000000000","message":"Will be removed.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":263,"context_line":"+----------+----------------------------------------------------------------------------+"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"If the check does not exist, the server responds with HTTP error 404"},{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_0c4bcfb1","line":266,"in_reply_to":"bab6814e_f6c2db51","updated":"2016-06-09 20:40:52.000000000","message":"I agree, lines 265 to 272 can be removed.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"If the check cannot be performed due to timeout, server responds with"},{"line_number":272,"context_line":"HTTP error 408 (Request timeout)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3f4e6596","line":269,"updated":"2016-05-19 18:42:47.000000000","message":"we should simplify the user experience if we can.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"If the check cannot be performed due to timeout, server responds with"},{"line_number":272,"context_line":"HTTP error 408 (Request timeout)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b1e6a5e5","line":269,"in_reply_to":"bab6814e_3f4e6596","updated":"2016-05-23 12:02:46.000000000","message":"I agree, and at the same time we need to allow user to pass in parameters (e.g. to check reachability of one port from another, both ports need to be specified) and notify them if some of them are missing/invalid.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"If the check cannot be performed due to timeout, server responds with"},{"line_number":272,"context_line":"HTTP error 408 (Request timeout)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_7c24d7c5","line":269,"in_reply_to":"bab6814e_50f8e1c4","updated":"2016-05-24 19:15:33.000000000","message":"I agree that we need to pass as little as necessary. Still I reckon two ports are necessary to be specified for reachability scenario: the source and a destination. In neutron API, one of the ports would be part of the URL (/v2/ports/{port_id}). The other would be passed in as a parameter (be it query string in GET or content body in POST method). I miss to understand the reason why passing parameters should create a security vulnerability.\n\nThe only concern from the security point of view is how the parameters are checked to prevent execution of malformed requests (buffer overflow, correct JSON syntax and similar vulnerabilities up to the point of accepting request and invoking the controller code are out of scope of this spec and should be handled in HTTP serving code). Special care needs to be taken to reject bad requests (e.g. invalid  parameter values), and only the parameters required to execute the health check should be used to propagate into relevant check logic. The controller that executes the health checks (passing in the arguments obtained from HTTP request) must consult the only authoritative source of the set of available parameters and their formats for the executed health check - that is the health check itself.\n\nHence the question should be raised not about whether to allow parameters, but about the actual set of allowed parameters and their expected formats for every and each health check.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":266,"context_line":"(Not Found)."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"If the check cannot be performed due to missing parameters, server"},{"line_number":269,"context_line":"responds with HTTP error 400 (Bad Request)."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"If the check cannot be performed due to timeout, server responds with"},{"line_number":272,"context_line":"HTTP error 408 (Request timeout)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_50f8e1c4","line":269,"in_reply_to":"bab6814e_b1e6a5e5","updated":"2016-05-24 00:42:56.000000000","message":"no we really don\u0027t. We can pass as little as it makes sense, and there\u0027s many ways in which this can be done more RESTfully. If we\u0027re indiscriminate in the amount of parameters we can get we might even create security vulnerabilities.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":278,"context_line":""},{"line_number":279,"context_line":"-  Collection diagnostic type of URLs allow for checks for nonexistent"},{"line_number":280,"context_line":"   resources, e.g. a check *orphaned\\_dhcp\\_namespace* in"},{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_5f19a987","line":281,"updated":"2016-05-19 18:42:47.000000000","message":"I am not sure I understand here, but it seems this is tied to one specific dhcp implementation","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":278,"context_line":""},{"line_number":279,"context_line":"-  Collection diagnostic type of URLs allow for checks for nonexistent"},{"line_number":280,"context_line":"   resources, e.g. a check *orphaned\\_dhcp\\_namespace* in"},{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_54564006","line":281,"in_reply_to":"bab6814e_5f19a987","updated":"2016-05-23 12:02:46.000000000","message":"Yes, this is to show an example of a check where demand for such a check already exists.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":287,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_0a1fe15f","line":284,"updated":"2016-05-19 18:42:47.000000000","message":"why? Every resources should have at least one health condition associated with it. In the most simplistic term *health* matches with the current *status* attribute we have on some resources.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":287,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_d628779c","line":284,"in_reply_to":"bab6814e_0a1fe15f","updated":"2016-05-23 12:02:46.000000000","message":"\u003e Why?\n\nBecause neutron cluster might be in an error state, e.g. a discrepancy of versions on controller node and the network node due to unsuccessful update on network node where plugin would expect agent to have some check defined that is not there.\n\n\u003e Every resources should have at least one health condition associated with it. In the most simplistic term *health* matches with the current *status* attribute we have on some resources.\n\nReturning status would be then duplication of API, is this wanted?\n\nI also don\u0027t think it is defined for all resources e.g. for subnets. What would be expected for /subnets/{id}/health to return?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":287,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_071a886e","line":284,"in_reply_to":"bab6814e_61b9c0ec","updated":"2016-06-09 20:40:52.000000000","message":"I don\u0027t find line 283 useful when it\u0027s kept generic as it is now. Explaining how this would work with ML2/OVS mech driver/OVS agent should not be done in this section, so I would just remove the bullet point in line 283.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":287,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_61b9c0ec","line":284,"in_reply_to":"bab6814e_7016c5f2","updated":"2016-05-24 19:15:33.000000000","message":"Let me explain the chain of calls from API to actual agent:\n\n Client --(1)--\u003e API --(2)--\u003e Plugin --(3)--\u003e Driver --(4)--\u003e Agent\n\nResult is returned in the reverse direction.\n\nIn this example, let\u0027s assume that a port is to be diagnosed:\n\n(1) Client invokes a request to /v2/ports/{id}/health.\n(2) API health controller checks whether a health check is registered for a port resource. If not, it rejects request, otherwise if given parameters fulfil the constraints set by the check, it invokes the health check execution in plugin.\n(3) Plugin executes the plugin part of the health check. If the check is provided by a driver, it delegates the check execution to the driver, otherwise the check can directly execute and return result.\n(4) Driver part of the check determines which agent should be responsible for execution and using RPC, it invokes agent part of the check.\n\nThis is how the call should proceed if it actually propagates to the agent level. The nature of the check might such that it is implemented in driver or even plugin, then it would return sooner.\n\nFor example, if ML2 is plugin, the driver might be mechanism driver (openvswitch) and agent would be ovs_neutron_agent. Port health would require checkint that a port exists and is up. Both of these checks can only be performed at node where the port is bound, hence all of the components (plugin, driver, agent) would be called for such a check.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":281,"context_line":"   /v2/subnets/**health**."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"-  Execution of a registered check from a plugin is always attempted,"},{"line_number":284,"context_line":"   and if not supported by a backend (driver, agent), an error is returned."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"-  Examples of possible diagnostic checks are at the end of this"},{"line_number":287,"context_line":"   blueprint."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_7016c5f2","line":284,"in_reply_to":"bab6814e_d628779c","updated":"2016-05-24 00:42:56.000000000","message":"I might have misunderstood what you mean, but what\u0027s is unclear to me is line 284. I am having a hard time visualize what you mean by driver/agent and plugin in this context.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":289,"context_line":"-  *Technical note:* It is possible that two different diagnostic checks"},{"line_number":290,"context_line":"   register themselves for the same name. To prevent confusion and potentially"},{"line_number":291,"context_line":"   misleading error codes, an error will be logged and all checks of that name"},{"line_number":292,"context_line":"   would be made unavailable."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Changes in Neutron CLI"},{"line_number":295,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_ca3b19d0","line":292,"updated":"2016-05-19 18:42:47.000000000","message":"I think we can live without this complexity.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":289,"context_line":"-  *Technical note:* It is possible that two different diagnostic checks"},{"line_number":290,"context_line":"   register themselves for the same name. To prevent confusion and potentially"},{"line_number":291,"context_line":"   misleading error codes, an error will be logged and all checks of that name"},{"line_number":292,"context_line":"   would be made unavailable."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Changes in Neutron CLI"},{"line_number":295,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_f487745e","line":292,"in_reply_to":"bab6814e_ca3b19d0","updated":"2016-05-23 12:02:46.000000000","message":"We indeed can, I can remove it from the spec.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":289,"context_line":"-  *Technical note:* It is possible that two different diagnostic checks"},{"line_number":290,"context_line":"   register themselves for the same name. To prevent confusion and potentially"},{"line_number":291,"context_line":"   misleading error codes, an error will be logged and all checks of that name"},{"line_number":292,"context_line":"   would be made unavailable."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Changes in Neutron CLI"},{"line_number":295,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_2c932bfc","line":292,"in_reply_to":"bab6814e_f487745e","updated":"2016-06-09 20:40:52.000000000","message":"I find myself reading the spec and making many of the same comments as Armando. There\u0027s no need for this complexity, we\u0027ll ensure that no two checks have the same name in the coding phase.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":294,"context_line":"Changes in Neutron CLI"},{"line_number":295,"context_line":"----------------------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Set of neutron CLI commands would be enhanced with a **diagnose** verb"},{"line_number":298,"context_line":"per each resource. Depending on presence of resource ID, There will be"},{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_0748c85a","line":297,"updated":"2016-06-09 20:40:52.000000000","message":"I think new CLI client features should go to the openstack client and not to the neutron client at this point. Armando, who would be a good person to ask here?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"961c72b8369b20f96e4980d2671281406b7573cb","unresolved":false,"context_lines":[{"line_number":294,"context_line":"Changes in Neutron CLI"},{"line_number":295,"context_line":"----------------------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Set of neutron CLI commands would be enhanced with a **diagnose** verb"},{"line_number":298,"context_line":"per each resource. Depending on presence of resource ID, There will be"},{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a9d85d2_f09aa8c4","line":297,"in_reply_to":"7aa08908_0748c85a","updated":"2016-06-20 10:08:37.000000000","message":"Yes. OSC is a must, while neutronclient is optional.http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html#developer-guide","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_cac5d98e","line":302,"updated":"2016-05-19 18:42:47.000000000","message":"I am still unclear about what you mean by \u0027collection\u0027. Something like a network or a subnet or a router can be seen as a collection, but it\u0027s still a single resource in its own merit (e.g. network has port-security attribute and a check can assess that security is enforced as requested). I think we should either make health request for collection resources return the health status of the individual resources it contain (but it\u0027s incredibly cumbersome), or they can be tailored  to specific attributes that apply to the individual resource (like in the example above). I\u0027d rather focus on the latter.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_1655871c","line":302,"in_reply_to":"7aa08908_39d24c35","updated":"2016-06-10 11:03:21.000000000","message":"This sample check was used because demand for it existed before this spec was started, see [1].\n\nTo the overall point, I believe that the existing-to-expected checks are valuable as they can abstract the operators from understanding all the details of what needs to be satisfied for a particular backend resource to validly exist. Still, the operators would have the information that something extraneous exists in the system that is usually managed by neutron code, e.g. orphaned dhcp napespaces or unused keepalived PID files remained after node restart.\n\n[1] https://github.com/bodenr/neutron/commit/bcdbc618db7ef59bc43c00495fd66c646bbae97f#diff-04c6e90faac2675aa89e2176d2eec7d8R277","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b0bdcdd9","line":302,"in_reply_to":"bab6814e_74b9cbcb","updated":"2016-05-24 00:42:56.000000000","message":"So this is not in sync to the example in line 309. If for collection you mean /v2/ports the response should simply be the enumeration of health info associated with the individual resources?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_39d24c35","line":302,"in_reply_to":"bab6814e_8eafba2a","updated":"2016-06-09 20:58:45.000000000","message":"\u003e Example of such a check is detecting orphaned qdhcp namespaces that do not belong to any resource network.\n\nThis feels shoe-horned in and added after the fact. It doesn\u0027t fit with the use cases defined in the beginning of the document: Something\u0027s not working, let\u0027s run a specific check on a specific resource so that Neutron can check that it thinks everything is alright.\n\nChecking if there are orphaned dhcp namespaces is an example of something that could be put in a script in a cron, but it isn\u0027t something that an admin would run because he thinks something is wrong.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_8eafba2a","line":302,"in_reply_to":"bab6814e_b0bdcdd9","updated":"2016-05-24 19:15:33.000000000","message":"No, it is not a bulk check on all existing resources belonging to the given collection; it is rather a check on unspecified resources.\n\nIn other words, resource-specific checks are from-expected-to-existing checks (check that whatever a given resource expects to be created (e.g. ports, namespaces) is really there in expected state). The checks on collections are verifying the other side of that relation, i.e. from-existing-to-expected and can be used e.g. for negative checks to validate cleanliness of node environment (for instance to check that there exists _no_ physical resource (port, namespace, or whatever is used for actual implementation) that would _not_ belong to any resource from the given collection.\n\nIt is for this reason that the actual checks on collections and their respective resources are set to be distinct (see line 177).\n\nExample of such a check is detecting orphaned qdhcp namespaces that do not belong to any resource network.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":299,"context_line":"two modes of operation, reflecting the API calls for collections and"},{"line_number":300,"context_line":"resources, respectively:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"Diagnostics of collections:"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"+------------+-------------------------------------------------------------------+"},{"line_number":305,"context_line":"| Syntax:    | *\u003cresource\u003e*\\ **-diagnose** \u003c*check*\\ \u003e [ --param1 value ... ]    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_74b9cbcb","line":302,"in_reply_to":"bab6814e_cac5d98e","updated":"2016-05-23 12:02:46.000000000","message":"The terms \u0027collection\u0027 and \u0027resource\u0027 used in this spec are used in the same sense as in API v2. For example /v2/ports, /v2/networks represent collections (ports, networks), and /v2/ports/{port_id}, /v2/networks/{network_id} are both examples of resources.\n\nA collection in this spec is not any kind of aggregation of subresources (like in router being viewed as a collection of ports).","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":316,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":317,"context_line":"| Maps to:   | POST /v2/\u003c*collection*\\ \u003e/\u003c*id*\\ \u003e/\\ **health**                                |"},{"line_number":318,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":319,"context_line":"| Example:   | port-diagnose --id *UUID* ping --ip 10.0.0.10                                  |"},{"line_number":320,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Implementation phases"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_aac0557d","line":319,"updated":"2016-05-19 18:42:47.000000000","message":"I don\u0027t think we\u0027d want to go this deep in exposing \u0027ping\u0027 capabilities.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":316,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":317,"context_line":"| Maps to:   | POST /v2/\u003c*collection*\\ \u003e/\u003c*id*\\ \u003e/\\ **health**                                |"},{"line_number":318,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":319,"context_line":"| Example:   | port-diagnose --id *UUID* ping --ip 10.0.0.10                                  |"},{"line_number":320,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Implementation phases"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_f0ae3597","line":319,"in_reply_to":"bab6814e_3420e3f6","updated":"2016-05-24 00:42:56.000000000","message":"If you need to verify the health status of a combined resource you can do by doing something like:\n\n/resource/id/health?other_resource\u003did","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":316,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":317,"context_line":"| Maps to:   | POST /v2/\u003c*collection*\\ \u003e/\u003c*id*\\ \u003e/\\ **health**                                |"},{"line_number":318,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":319,"context_line":"| Example:   | port-diagnose --id *UUID* ping --ip 10.0.0.10                                  |"},{"line_number":320,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Implementation phases"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_3420e3f6","line":319,"in_reply_to":"bab6814e_aac0557d","updated":"2016-05-23 12:02:46.000000000","message":"Yet we need to expose some kind of parameterization to be able to test for reachability of one resource from another (check that it is possible to e.g. ping an external IP from a router port)","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":316,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":317,"context_line":"| Maps to:   | POST /v2/\u003c*collection*\\ \u003e/\u003c*id*\\ \u003e/\\ **health**                                |"},{"line_number":318,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":319,"context_line":"| Example:   | port-diagnose --id *UUID* ping --ip 10.0.0.10                                  |"},{"line_number":320,"context_line":"+------------+--------------------------------------------------------------------------------+"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Implementation phases"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b702d8b2","line":319,"in_reply_to":"bab6814e_f0ae3597","updated":"2016-05-24 19:15:33.000000000","message":"That is true, and is expressed by the need for parameters. The need for parameters applies regardless of the HTTP method, i.e. whether the parameters are passed in via POST content in JSON encoding, or via GET query parameters (like parameter other_resource here).\n\nPlease find further details on combined resources handling in comment to line 226.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":324,"context_line":""},{"line_number":325,"context_line":"There will be three phases in the implementation:"},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"1. *Neutron server-side changes:* introduction of an extension that"},{"line_number":328,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":329,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":330,"context_line":"   of logic in agents to supply diagnostic information upon request,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_f9f0c4cb","line":327,"updated":"2016-06-09 20:58:45.000000000","message":"For the reference implementation, it\u0027s not clear if you want to implement checks in the existing agents, or write new agents. Would the L3 agent register an RPC endpoint to check the existence of namespaces and ping stuff, or would we supply a brand new \u0027health-check\u0027 agent?\n\nThe latter will provide cleaner code, while the former will not require work in deployment tools.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":324,"context_line":""},{"line_number":325,"context_line":"There will be three phases in the implementation:"},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"1. *Neutron server-side changes:* introduction of an extension that"},{"line_number":328,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":329,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":330,"context_line":"   of logic in agents to supply diagnostic information upon request,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_7181754d","line":327,"in_reply_to":"7aa08908_f9f0c4cb","updated":"2016-06-10 11:03:21.000000000","message":"Good point, I\u0027ll address it in the next iteration. For now, the intention is to implement it in existing agents. The POC [1] illustrates how this would go, namely commits [2] (changes in existing agents) and [3] (implementation of a check in the agent)\n\n[1] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:tmp-health-checking-pub\n[2] https://review.openstack.org/#/c/322161/\n[3] https://review.openstack.org/#/c/322162/","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":327,"context_line":"1. *Neutron server-side changes:* introduction of an extension that"},{"line_number":328,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":329,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":330,"context_line":"   of logic in agents to supply diagnostic information upon request,"},{"line_number":331,"context_line":"   and an implementation of a **ping** check."},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_aa6e9593","line":330,"updated":"2016-05-19 18:42:47.000000000","message":"whether the check relies on an agent-side component should be specific to the check itself and be hidden to the server.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":327,"context_line":"1. *Neutron server-side changes:* introduction of an extension that"},{"line_number":328,"context_line":"   controls presence of **health** URL part; introduction of the new"},{"line_number":329,"context_line":"   API controllers for handling **health** subroots; implementation"},{"line_number":330,"context_line":"   of logic in agents to supply diagnostic information upon request,"},{"line_number":331,"context_line":"   and an implementation of a **ping** check."},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"2. *Neutron CLI changes:* enhance CLI with commands to invoke"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_94a6e8ab","line":330,"in_reply_to":"bab6814e_aa6e9593","updated":"2016-05-23 12:02:46.000000000","message":"That is true, and the \"implementation of logic in agents\" is meant to give working example on how to implement the scenario where it does. When it does not, is actually simpler. It is not meant in any way to suggest that all checks would be implemented with agent counterpart.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_8a9ab161","line":347,"updated":"2016-05-19 18:42:47.000000000","message":"Up until now I still do not have a good/clear idea of what you intend to characterize as the health of key resources like ports, let alone the health of combined resources, e.g. how is the health of the relationship between two resources (e.g. can two ports communicate to one another?) I was hoping this blueprint would model something specific to Neutron rather than define a general framework. Fixing ideas on practical needs would help us better figure out implementation details. Right now everything is very blurred.\n\nHaving said that I think this is a good start and we can iterate.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_11e47139","line":347,"in_reply_to":"7aa08908_27f184ce","updated":"2016-06-10 11:03:21.000000000","message":"Thanks, will be included in the next iteration.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_27f184ce","line":347,"in_reply_to":"bab6814e_6fd531b8","updated":"2016-06-09 20:40:52.000000000","message":"It makes sense to define \u0027reachability\u0027 further. For example, answering the question stated in the first paragraph: Why can\u0027t I ping my floating IP? \n\n* Implementing health for a floating IP ID\n* Checking the existence of a router, it\u0027s interfaces and IPs\n* Enabling pings between the router and a VM\n* Checking if security group rules accept incoming ICMP\n\nImplementing those checks will force us to see if we can send commands to network and compute nodes and making server-side database checks.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"e23507883220275f4f2e89fdb964c16f758a84e5","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_d7e6b242","line":347,"in_reply_to":"bab6814e_8a9ab161","updated":"2016-05-23 12:02:46.000000000","message":"Hopefully the case of health of ports was addressed in the earlier replies to the comments, namely health of relationship between the ports.\n\nWhat I\u0027m trying to achieve is to provide a framework that serves as a basis for troubleshooting and not to address troubleshooting itself. This basis is vital for troubleshooting, troubleshooting cannot be implemented without having the health checks. Once this BP would be implemented, the troubleshooting implementors can then concentrate on answering questions of \"what\" is necessary to troubleshoot a particular resource/scenario, while the means \"how\" to incorporate the checks into neutron would be already in place, prepared by this blueprint.\n\nHaving said that, I don\u0027t intend to finish the work once the framework would be there. The intention is to get the troubleshooting there - but only after it would be easy to add individual health checks, i.e. after finishing work on this BP.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"539b3bf0dcd660bd0bf35f098aed379cd1797abf","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_6fd531b8","line":347,"in_reply_to":"bab6814e_b092ed49","updated":"2016-05-24 19:15:33.000000000","message":"To prevent this vacuum implementation of a check framework, and also to set an example implementation that can be further extended according to the needs, a reachability scenario will be implemented along the way. Would this mitigate this concern?","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d2ec8395e3214472242854fae4a5ee7471c9499d","unresolved":false,"context_lines":[{"line_number":344,"context_line":"   *  Alternative 2: A sample troubleshooting logic will be implemented in"},{"line_number":345,"context_line":"      neutron server to illustrate how to use API to troubleshoot."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Future work"},{"line_number":348,"context_line":"-----------"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_b092ed49","line":347,"in_reply_to":"bab6814e_d7e6b242","updated":"2016-05-24 00:42:56.000000000","message":"I figured that you were thinking along those lines. My concern is that by doing so we\u0027d be developing this framework in the vacuum, whereas I think we should try and design both, the framework and the checks that makes sense for Neutron so that we get an earlier feedback that the framework is solid.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":351,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":352,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"| {"},{"line_number":355,"context_line":"|   \"check1\": {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_67a0aca6","line":352,"updated":"2016-06-09 20:40:52.000000000","message":"auto completion typically works without an internet connection. I don\u0027t think it\u0027s feasible to have auto completion work based off a REST call to the server.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":349,"context_line":""},{"line_number":350,"context_line":"The diagnostic extension registers all checks. As such, it would able to"},{"line_number":351,"context_line":"return list of all available checks, for sake of e.g. CLI tools"},{"line_number":352,"context_line":"autocompletion. Format of a description of a single check may be this:"},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"| {"},{"line_number":355,"context_line":"|   \"check1\": {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_11d8f11c","line":352,"in_reply_to":"7aa08908_67a0aca6","updated":"2016-06-10 11:03:21.000000000","message":"In this case, the autocompletion would be done in the same manner as for existing commands. I.e. autocompletion would be done on command level (port-he\u003ctab\u003e would autocomplete to port-health similarly to e.g. port-up\u003ctab\u003e), but not on parameter level (similarly to current behaviour where parameters like e.g. --admin-state-up or port ID are not autocompleted). In this regards, the diagnostic health check name is a parameter (similarly to resource ID).\n\nShould neutron/openstack client implement a troubleshooting scenario, it would be its own command, hence autocompletion would be independent of any active connections as all the necessary (autocompletion) information would be included with the CLI command definition.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":375,"context_line":"If the check returns any nonstandard result fields, they are described"},{"line_number":376,"context_line":"in the **result\\_fields** output parameter."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Comparison with related proposals"},{"line_number":379,"context_line":"---------------------------------"},{"line_number":380,"context_line":""},{"line_number":381,"context_line":"There are related proposals, addressing the diagnostics and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_4ab729d8","line":378,"updated":"2016-05-19 18:42:47.000000000","message":"I\u0027d simply provide the references and avoid pulling this content here, as it makes the spec busy for no evident gain.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"e78f565e47aed4137219b35faa4b682289bfd7f0","unresolved":false,"context_lines":[{"line_number":375,"context_line":"If the check returns any nonstandard result fields, they are described"},{"line_number":376,"context_line":"in the **result\\_fields** output parameter."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Comparison with related proposals"},{"line_number":379,"context_line":"---------------------------------"},{"line_number":380,"context_line":""},{"line_number":381,"context_line":"There are related proposals, addressing the diagnostics and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_b9c91c5d","line":378,"in_reply_to":"bab6814e_4ab729d8","updated":"2016-06-09 20:58:45.000000000","message":"Agreed.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6c11f635d1174f73c31ea6e96e0311e839e867b1","unresolved":false,"context_lines":[{"line_number":467,"context_line":"some limited remediation."},{"line_number":468,"context_line":""},{"line_number":469,"context_line":"Sample diagnostic checks"},{"line_number":470,"context_line":"------------------------"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"This section contains sample URLs that maps a check to an API URL."},{"line_number":473,"context_line":"*The sample checks are taken from the related RFEs.* Please note that"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bab6814e_cad2f9ff","line":470,"updated":"2016-05-19 18:42:47.000000000","message":"This seems too implementation specific. I\u0027d rather see how you could expose checks in a technology agnostic fashion","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"908c13b4020cd5b16b8e5a6ec0a34146d111e75f","unresolved":false,"context_lines":[{"line_number":467,"context_line":"some limited remediation."},{"line_number":468,"context_line":""},{"line_number":469,"context_line":"Sample diagnostic checks"},{"line_number":470,"context_line":"------------------------"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"This section contains sample URLs that maps a check to an API URL."},{"line_number":473,"context_line":"*The sample checks are taken from the related RFEs.* Please note that"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_ec246ac7","line":470,"in_reply_to":"7aa08908_67dc2c19","updated":"2016-06-10 11:03:21.000000000","message":"API would always remain the same (having the /health subroot) while maintaining the flexibility of changing the set of available checks. This is analogous to existing API of e.g. networks:\n\nIn networks, depending on the network type (provider:physical_network attribute) of a particular network given by ID, additional parameters are accepted or rejected (provider:segmentation_id, provider:physical_network). In this settings, health check name is analogous to network ID (check name is unique for a given resource type in similarly as ID uniquely identifies a network), and the set of accepted parameters changes according to the nature of the check similarly to changing available parameters according to the nature of the network.\n\nSet of available checks depends on particular installation, allowing for easy extension / change, according to user needs.\n\nPlease see also POC that provides illustration of all what is needed to register a new check in [1]. It also illustrates that there is no change in API. Applying the patch [1] is rather analogous to net-create command (following the analogy above) as it registers a new check with a unique name (with obvious differences that there are no changes in database and instead of ID, the check is available by its name).\n\n[1] https://review.openstack.org/#/c/322162/","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"0b51e7187217432acfc00f828dc49085d2cae655","unresolved":false,"context_lines":[{"line_number":467,"context_line":"some limited remediation."},{"line_number":468,"context_line":""},{"line_number":469,"context_line":"Sample diagnostic checks"},{"line_number":470,"context_line":"------------------------"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"This section contains sample URLs that maps a check to an API URL."},{"line_number":473,"context_line":"*The sample checks are taken from the related RFEs.* Please note that"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7aa08908_67dc2c19","line":470,"in_reply_to":"bab6814e_cad2f9ff","updated":"2016-06-09 20:40:52.000000000","message":"This is the sticking point for me with alternative 1. I don\u0027t know how we can get past a scenario where the API ends up tied up to the reference implementation, which is what is implied below. That is kind of the bottom line for me in championing alternative 2.","commit_id":"a31b5f3e6fbeb379b6bffaecc4b52beb70d71735"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":22,"context_line":"This blueprint describes generic API for diagnostics of real state of"},{"line_number":23,"context_line":"neutron resources, and. While it provides examples of the actual diagnostic"},{"line_number":24,"context_line":"checks to be implemented, it should not be treated as a base that lists"},{"line_number":25,"context_line":"all of them."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem Description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_09b9e579","line":25,"updated":"2016-07-09 00:40:55.000000000","message":"Agreed, though I feel the objective of this spec is to provide at least the implementation of a couple of examples, to be used as a pattern for others to come in the future.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":22,"context_line":"This blueprint describes generic API for diagnostics of real state of"},{"line_number":23,"context_line":"neutron resources, and. While it provides examples of the actual diagnostic"},{"line_number":24,"context_line":"checks to be implemented, it should not be treated as a base that lists"},{"line_number":25,"context_line":"all of them."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem Description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_a981b191","line":25,"updated":"2016-07-09 00:40:55.000000000","message":"Agreed, though I feel the objective of this spec is to provide at least the implementation of a couple of examples, to be used as a pattern for others to come in the future.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ce818afc3cd60eff3fb4f7b0d5c37302075ec944","unresolved":false,"context_lines":[{"line_number":22,"context_line":"This blueprint describes generic API for diagnostics of real state of"},{"line_number":23,"context_line":"neutron resources, and. While it provides examples of the actual diagnostic"},{"line_number":24,"context_line":"checks to be implemented, it should not be treated as a base that lists"},{"line_number":25,"context_line":"all of them."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem Description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_bc87875f","line":25,"in_reply_to":"1aa78d24_a981b191","updated":"2016-08-12 04:35:08.000000000","message":"Where have I heard that before? ;)","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ce818afc3cd60eff3fb4f7b0d5c37302075ec944","unresolved":false,"context_lines":[{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"One of the common questions seen at ask.openstack.org and mailing lists is"},{"line_number":31,"context_line":"\"Why can\u0027t I ping my floating IP address?\". Usually, there are common"},{"line_number":32,"context_line":"steps in the diagnostics required to answer the question involving"},{"line_number":33,"context_line":"determination of relevant namespaces, pinging the instance from that"},{"line_number":34,"context_line":"namespaces etc. Currently, these steps need to be performed manually,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_827b3ebd","line":31,"updated":"2016-08-12 04:35:08.000000000","message":"I think our mindset is one reason that it is difficult for us developers to grasp a spec proposal for automated diagnostics, troubleshooting, and remediation like this.\n\nI have done a lot of manual troubleshooting since I started working with Neutron. Each time that I root caused a problem, I tried to develop a solution to that problem so that it wouldn\u0027t happen to others ever again. Occasionally, I\u0027ll apply a quick fix to get the user back on his feet but then I want to follow that up with a permanent fix and get it through the CI pipeline before I need to help with that same issue again.\n\nI don\u0027t normally think that I should create a separate troubleshooting and remediation tool for it because I feel like the time that I spent on that would be better spent make the system itself more robust.\n\nI\u0027m not trying to say that this is not a worth-while effort. I\u0027m just trying to say that maybe I\u0027m not quite the right guy to know how to make it happen. :)","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ce818afc3cd60eff3fb4f7b0d5c37302075ec944","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little detail of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"},{"line_number":43,"context_line":"issue."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_a2f12297","line":40,"updated":"2016-08-12 04:35:08.000000000","message":"What about the kinds of issues that occur because of human error or a lack of understanding of how the system works. For example, ensuring that the security groups are configured correctly. Or, ensuring that a router has been connected between a tenant private network and the external floating IP network. Are those in scope?\n\nI think, in general, the scope of this spec is unclear.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little detail of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"},{"line_number":43,"context_line":"issue."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_f8612406","line":40,"in_reply_to":"9ad45d7e_2a7b3f2b","updated":"2016-08-18 08:55:52.000000000","message":"Absolutely, that is the primary intent of diagnostics proposed in this spec.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little detail of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"},{"line_number":43,"context_line":"issue."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_6da9d124","line":40,"in_reply_to":"9ad45d7e_a2f12297","updated":"2016-08-18 08:55:52.000000000","message":"The issues caused by misunderstanding are also to be covered by checks, especially security group settings. The spec covers only few basic checks, and leaves the implementation of the check framework extensible to enable straightforward addition of new checks per user feedback.\n\n\u003e I think, in general, the scope of this spec is unclear.\n\nThe spec proposes an extensible framework with three sample checks. It does not propose the complete solution and complete list of checks because new checks would be added for new features as well for recurring (misconfiguration) issues, based on user needs.\n\nThe scope is therefore the framework and the sample checks (see the section `Implemented health checks`_), yet it discusses the diagnostics more generally to state the requirements for the framework.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":14535,"name":"Amit Saha","email":"amsaha@gmail.com","username":"amsaha"},"change_message_id":"688492f9fe8a958a11be7b461223814116443595","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Neutron currently provides data on how the resources *should* be"},{"line_number":39,"context_line":"configured. However, it provides only a very little diagnostics"},{"line_number":40,"context_line":"information reflecting *actual* resource state. Hence if an issue"},{"line_number":41,"context_line":"occurs, user is often left with only a little detail of what works and"},{"line_number":42,"context_line":"what not, and has to manually crawl affected hosts to troubleshoot the"},{"line_number":43,"context_line":"issue."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_2a7b3f2b","line":40,"in_reply_to":"9ad45d7e_a2f12297","updated":"2016-08-12 09:02:37.000000000","message":"We have been working on some basic neutron diagnostics and Carl hit the nail on the head. Just verifying all the configuration is a big help.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"ce818afc3cd60eff3fb4f7b0d5c37302075ec944","unresolved":false,"context_lines":[{"line_number":47,"context_line":"via API calls, reducing amount of needed manual work."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"For the following text, it is necessary to clarify difference of"},{"line_number":50,"context_line":"diagnostics and troubleshooting:"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_a24802cd","line":50,"updated":"2016-08-12 04:35:08.000000000","message":"You\u0027ve made an interesting distinction. For diagnostics, it seems like one would need to be in fairly close contact with the system, sometimes reaching under the hood to get data that only the system can provide.\n\nSince troubleshooting simply uses the diagnostics data, is there any reason that automated troubleshooting code should be under Neutron? Your diagram seems to imply that it would run on the server side. I assume that means that the troubleshooting runs under the API.\n\nWould it be reasonable to provide diagnostics data through the API to allow third-party projects to analyze it and try to make sense of it? Or, is the amount of diagnostics just too much? I think Armando has a few good points below that touch on this. It might not make sense to supply low-level diagnostics data through the API, especially to an end user. Maybe an admin operator could make more sense of the data because they are normally more involved in the lower level details. I really don\u0027t know the answer, read this as more of my stream of thought without any particular conclusions at the moment.\n\nI have very little expertise with creating automated troubleshoot and diagnostics tools. So, I\u0027m just thinking out loud here.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":14535,"name":"Amit Saha","email":"amsaha@gmail.com","username":"amsaha"},"change_message_id":"688492f9fe8a958a11be7b461223814116443595","unresolved":false,"context_lines":[{"line_number":47,"context_line":"via API calls, reducing amount of needed manual work."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"For the following text, it is necessary to clarify difference of"},{"line_number":50,"context_line":"diagnostics and troubleshooting:"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_caa2634b","line":50,"in_reply_to":"9ad45d7e_a24802cd","updated":"2016-08-12 09:02:37.000000000","message":"We tried doing some ovs diagnostics in https://github.com/openstack/python-don and our experience also has been that it is difficult to do things from inside Neutron (maybe it just appears daunting). Instead we chose the approach to automating what a human would do - run commands and look at the output and ensure that the data looks good. In general we found that we need a combination of openstack, ovs, and ssh commands to get to what we wanted. \n\nAlso, I agree with the fact that we need to expose the internal data (as much as possible).","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":47,"context_line":"via API calls, reducing amount of needed manual work."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"For the following text, it is necessary to clarify difference of"},{"line_number":50,"context_line":"diagnostics and troubleshooting:"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"-  *Diagnostics* is a plain description of the current state"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_43920e4d","line":50,"in_reply_to":"9ad45d7e_caa2634b","updated":"2016-08-18 08:55:52.000000000","message":"These are interesting comments. I\u0027d like to invite you to check intro of the previous version of this spec [1] and let me know whether you would prefer rather Alternative 1 that leaves the troubleshooting on external tools?\n\n[1] https://review.openstack.org/#/c/308973/4/specs/newton/diagnostics.rst","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":89,"context_line":"   resource (e.g. port diagnostics, reachability of two ports, floating"},{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_892af58e","line":90,"updated":"2016-07-09 00:40:55.000000000","message":"can you provide a practical example for both?\n\nFor instance:\n\n/v2/ports/12745d69-2bcd-4350-ba1d-b52317722835/health\n\nor\n\n/v2/ports/health\n\nI am not sure I understand the use case for the latter.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":89,"context_line":"   resource (e.g. port diagnostics, reachability of two ports, floating"},{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_d4a7dd08","line":90,"in_reply_to":"1aa78d24_892af58e","updated":"2016-07-21 11:36:01.000000000","message":"There is not necessarily usecase for every resource-collection pair.\n\nFor /v2/ports/health, e.g. checking that there is no unexpected flow for neutron-managed ports in br-int in OVS settings. Boden\u0027s PBAM is among others about checking network orphaned namespaces which fits precisely to  /v2/networks/health.\n\nFor /v2/ports/UUID/health, the examples are the two scenarios in Implemented health checks section starting at line 196.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":89,"context_line":"   resource (e.g. port diagnostics, reachability of two ports, floating"},{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_ced92f59","line":90,"in_reply_to":"bacf61ea_5db0a243","updated":"2016-09-07 11:47:45.000000000","message":"I agree that running full suite of all tests in e.g. network collection would be overkill. For that reason, there are \"scenarios\" defined that restrict the checks being run. There is also space for the \"extra information\" that can make these calls practical for admins, by e.g. specifying particular node name in parameters of that call.\n\n\u003e but for which br-int?\n\nThat way one would also be able to limit \"which br-int\" to inspect to a specific node.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"-  /v2/*collection*/*object\\_id*/**health** - for diagnostics of a named"},{"line_number":89,"context_line":"   resource (e.g. port diagnostics, reachability of two ports, floating"},{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_5db0a243","line":90,"in_reply_to":"dada55a8_d4a7dd08","updated":"2016-07-29 00:23:19.000000000","message":"but for which br-int? For all of them? Not sure how practical that would be. Same for the latter, unless a body would specify extra information, but having said that this seems complex to start with. Having just one new subroot would be already a good achievement.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_c9335d12","line":93,"updated":"2016-07-09 00:40:55.000000000","message":"not sure I understand the relationship between /v2/*collection*/**health**  and the example. Why would anyone want to know if there are orphaned PID files? It sounds too implementation specific.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_26ba146f","line":93,"in_reply_to":"1aa78d24_c9335d12","updated":"2016-07-21 11:36:01.000000000","message":"There is demand for such type of checks as demonstrated by Boden\u0027s PBAM and check for orphaned namespaces. It is implementation specific because it is inevitable in diagnostics to handle low-level resources, even if the diagnostics is executed for a high-level concept (port, networks)","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_5447734a","line":93,"in_reply_to":"1ac06dbe_a7510665","updated":"2016-09-07 11:47:45.000000000","message":"Depending on what is meant by \"People\":\n\n* Admin and ordinary users - they will need to understand OSC commands (e.g. \"os port health my-port\") and their parameters, nothing else\n\n* Developers - when developing a new health check, developer needs to understand where to place a health check and naming conventions. That is really straightforward, see e.g. [1]\n\nHence I do not see where you envision the UX complexity coming from?\n\n\u003e Validating no orphaned PID files is something that a user should never ever worry about!\n\nI agree they _should_ not. [2]\n\n[1] https://review.openstack.org/#/c/322162/\n[2] https://bugs.launchpad.net/neutron/kilo/+bug/1561046","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"136539d4cda0b6d85fe09aed22b6c2cc7e797574","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ac06dbe_a7510665","line":93,"in_reply_to":"3ac371cc_b5b33509","updated":"2016-08-24 22:12:59.000000000","message":"It\u0027s UX complexity. People need to understand this API without having to read a 500 pages manual, because they generally won\u0027t and if they did, the more complex the UI is, the higher the chance they get it wrong. My point is: we should strike a balance between ease of use of the API and effectiveness in helping the user pinpoint the error and figure out a strategy to recover from it. Validating no orphaned PID files is something that a user should never ever worry about!","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_b5b33509","line":93,"in_reply_to":"bacf61ea_9d569ad0","updated":"2016-08-18 08:55:52.000000000","message":"I don\u0027t see any big complexity from client entering the command into OSC cli, placing the request into mq, retrieving and aggregating the result from managed hosts and returning the result to the client.\n\nWhere do you envision the complexity coming from?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":90,"context_line":"   IP health)"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"-  /v2/*collection*/**health** - for diagnostics of the resource"},{"line_number":93,"context_line":"   collection (e.g. validating that there are no orphaned PID files)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The sets of diagnostic checks for a collection and for a resource are"},{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_9d569ad0","line":93,"in_reply_to":"dada55a8_26ba146f","updated":"2016-07-29 00:23:19.000000000","message":"I am honestly not seeing how this use case would work in practice. I fear that the complexity to build such a request (and fulfill it) is introducing a high bar.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."},{"line_number":97,"context_line":"Resource-specific checks represent from-expected-to-existing checks, i.e."},{"line_number":98,"context_line":"check that whatever a given resource expects to be created (e.g."},{"line_number":99,"context_line":"ports, namespaces) is really there in expected state. The checks on"},{"line_number":100,"context_line":"collections are verifying the other side of that relation, i.e."},{"line_number":101,"context_line":"from-existing-to-expected and can be used e.g. for negative checks to"},{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_09156548","line":99,"updated":"2016-07-09 00:40:55.000000000","message":"I personally feel we should limit ourselves to API resources. Namespace aren\u0027t.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."},{"line_number":97,"context_line":"Resource-specific checks represent from-expected-to-existing checks, i.e."},{"line_number":98,"context_line":"check that whatever a given resource expects to be created (e.g."},{"line_number":99,"context_line":"ports, namespaces) is really there in expected state. The checks on"},{"line_number":100,"context_line":"collections are verifying the other side of that relation, i.e."},{"line_number":101,"context_line":"from-existing-to-expected and can be used e.g. for negative checks to"},{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_90ec5a2b","line":99,"in_reply_to":"1aa78d24_09156548","updated":"2016-07-21 11:36:01.000000000","message":"Let me clarify types of resources:\n* High-level resources - types of resources available from neutron API (ports, networks, floatingips)\n* Low-level resources - internal resources (physical ports, OVS bridges, Linux bridges, namespaces, files, ...)\n\nDiagnostics scenario defines for a high-level resource (or resource collection) a set of checks that verify that low-level resources are in expected state according to the high-level resource declaration. For example, that a (high-level) port for DHCP service has a corresponding namespace defined in the system and that a (low-level) port defined in that namespace, that this port is up and IP address is set etc.\n\nHence the API is limited to API resources, however diagnostics is not as it needs to verify that the low-level resources are there and in expected state.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"136539d4cda0b6d85fe09aed22b6c2cc7e797574","unresolved":false,"context_lines":[{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."},{"line_number":97,"context_line":"Resource-specific checks represent from-expected-to-existing checks, i.e."},{"line_number":98,"context_line":"check that whatever a given resource expects to be created (e.g."},{"line_number":99,"context_line":"ports, namespaces) is really there in expected state. The checks on"},{"line_number":100,"context_line":"collections are verifying the other side of that relation, i.e."},{"line_number":101,"context_line":"from-existing-to-expected and can be used e.g. for negative checks to"},{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ac06dbe_67ed4e8b","line":99,"in_reply_to":"3ac371cc_b5e7b5aa","updated":"2016-08-24 22:12:59.000000000","message":"I thought I had explained it.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."},{"line_number":97,"context_line":"Resource-specific checks represent from-expected-to-existing checks, i.e."},{"line_number":98,"context_line":"check that whatever a given resource expects to be created (e.g."},{"line_number":99,"context_line":"ports, namespaces) is really there in expected state. The checks on"},{"line_number":100,"context_line":"collections are verifying the other side of that relation, i.e."},{"line_number":101,"context_line":"from-existing-to-expected and can be used e.g. for negative checks to"},{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_b5e7b5aa","line":99,"in_reply_to":"bacf61ea_ddb652db","updated":"2016-08-18 08:55:52.000000000","message":"User would not be presented with low-level details, only high-level message (e.g. \u0027DHCP not responding\u0027) while the details would be supplied to admins. See paragraph at line 181 for specific rules driving this distinction.\n\nCarl @ line 50 mentions \"Maybe an admin operator could make more sense of the data because they are normally more involved in the lower level details.\" So I guess there is certain chance that a super user would understand the these issues.\n\nIMHO, neutron server-side troubleshooting should be rather simplistic. Should server-side troubleshooting fail, the results of diagnostic checks would be presented to the admins who would analyse these further and take appropriate actions.\n\nHence, where do you see the \"extra depth of analysis\" coming from?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":96,"context_line":"generally different. Each check targets a particular collection/resource."},{"line_number":97,"context_line":"Resource-specific checks represent from-expected-to-existing checks, i.e."},{"line_number":98,"context_line":"check that whatever a given resource expects to be created (e.g."},{"line_number":99,"context_line":"ports, namespaces) is really there in expected state. The checks on"},{"line_number":100,"context_line":"collections are verifying the other side of that relation, i.e."},{"line_number":101,"context_line":"from-existing-to-expected and can be used e.g. for negative checks to"},{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_ddb652db","line":99,"in_reply_to":"dada55a8_90ec5a2b","updated":"2016-07-29 00:23:19.000000000","message":"It sounds to me that we\u0027re mixing low level details with high level ones. A user only knows what a port is, a super user is not expect to understand what a namespace is, and how certain logical resources are realized. I think it\u0027s dangerous to expect the user to understand or supply details about low level resources when interacting with the API.\n\nI agree that there\u0027s a certain degree of lower level constructs that a user must be made aware of, but not all of them. To the example you\u0027re referring to for instance, it would suffice to know that there is an active and bound dhcp service with a sane lease file. If there isn\u0027t, that\u0027s enough cue for the trained user to go and troubleshoot the specific DHCP problem.\n\nIn other words we do not have to go in ultra depth for this framework to be useful. And the extra depth of analysis you seem to imply would make the cost of implementing such checks prohibitive.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"},{"line_number":103,"context_line":"exists *no* physical resource (port, namespace, config directories, PID files,"},{"line_number":104,"context_line":"or whatever is used in the implementation) that would *not* belong to any"},{"line_number":105,"context_line":"registered resource from the given collection."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The list of available checks is obtained dynamically on startup"},{"line_number":108,"context_line":"in the following way:"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_cc01ab06","line":105,"updated":"2016-07-09 00:40:55.000000000","message":"this paragraph is somewhat obscure. Can you try to use other words to express what you\u0027re trying to say? Perhaps an example would help.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":102,"context_line":"validate cleanliness of node environment (for instance to check that there"},{"line_number":103,"context_line":"exists *no* physical resource (port, namespace, config directories, PID files,"},{"line_number":104,"context_line":"or whatever is used in the implementation) that would *not* belong to any"},{"line_number":105,"context_line":"registered resource from the given collection."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The list of available checks is obtained dynamically on startup"},{"line_number":108,"context_line":"in the following way:"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_10c86aa5","line":105,"in_reply_to":"1aa78d24_cc01ab06","updated":"2016-07-21 11:36:01.000000000","message":"Please check reply to line 99, it hopefully sheds more light to the intent. \"Expected\" in the paragraph above is meant as the expected state of low-level resources according to what is declared in high-level resources (e.g. veth pair exists, is correctly connected up to OVS bridge), while \"existing\" is the actual state of low-level resources determined by inspecting them.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":125,"context_line":"invocation to the plugin that has defined the executed health check."},{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_2c578f03","line":128,"updated":"2016-07-09 00:40:55.000000000","message":"even though that might be one way to do it, I would like to explore an implementation strategy that would not involve an existing driver. For instance we may even have a new ML2 mech driver for that job.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":125,"context_line":"invocation to the plugin that has defined the executed health check."},{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_ca9bba64","line":128,"in_reply_to":"1aa78d24_2c578f03","updated":"2016-07-21 11:36:01.000000000","message":"Can you be more specific? New ML2 mech driver just for checking health?\nSuch a mech driver would need to understand internals of the \"operating\" mech driver so that it can provide diagnostic information. That means that there would be two places where the logic of a particular mechanism would be stored - operating mech driver and health checking mech driver. These two will have to be kept in sync. Is this intended?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"136539d4cda0b6d85fe09aed22b6c2cc7e797574","unresolved":false,"context_lines":[{"line_number":125,"context_line":"invocation to the plugin that has defined the executed health check."},{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ac06dbe_a78626b7","line":128,"in_reply_to":"9ad45d7e_9134524a","updated":"2016-08-24 22:12:59.000000000","message":"I agree that the underlying details must be technology dependent, the devil is in the details of how this happens. We can perhaps better discuss this point when looking at the code proposal.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"bddb6b6308c8da662af2dea976f9f3c695f3fce6","unresolved":false,"context_lines":[{"line_number":125,"context_line":"invocation to the plugin that has defined the executed health check."},{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_9134524a","line":128,"in_reply_to":"bacf61ea_7d45a6b1","updated":"2016-08-11 14:26:08.000000000","message":"I\u0027m not following Armando.\n\nThe API is plugin agnostic, the implementation is specific to the architecture of the configured plugin. For example, floating IPs in the reference implementation are implemented via the L3 agent and virtual routers. We need the implementation of diagnostics to be aware of these details. So, like the create_port API, Hynek wants to have the API layer delegate the API call to the core plugin. In these case of ML2, I think we have to further differentiate between something like the reference implementation and ODL, and that is the mechanism driver(s).","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":125,"context_line":"invocation to the plugin that has defined the executed health check."},{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_7d45a6b1","line":128,"in_reply_to":"dada55a8_ca9bba64","updated":"2016-07-29 00:23:19.000000000","message":"Going back to this, I don\u0027t think that making this an ML2 responsibility (of the plugin or the mech driver) is viable, otherwise the diagnostic framework cannot be plugin agnostic. A diagnostic check would have to understand the internals of a specific driver technology but muddling them together is not the answer to keep them integrated (or in sync as you say) otherwise the maintenance cost is gonna sky rocket.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"},{"line_number":132,"context_line":"diagnostics, i.e. description of the actual state compared to expected state."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_47480d8b","line":129,"updated":"2016-07-14 13:20:02.000000000","message":"The more RPC calls for a single flow, the more complexity and cost we incur. We can have code reusability and IMO simplicity even if we send \u0027mega\u0027 RPC calls to agents, as long as the code on the agent side is reusable and composed correctly.\n\nFor example, if the server wants an agent to health check a FIP via a couple of pings and checking the existence of resources such as namespaces and IP addresses, instead of several RPCs going back and forth, we send one with the required info about the FIP and move some of the logic to the agent. I don\u0027t think this is a case of increased complexity, I think this is a case of moving the complexity and that the overall complexity would be either reduced or stay the same. I do think that this is something we could revisit come implementation time.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":126,"context_line":"From there, the execution is specific to each plugin. In case of ML2, the check"},{"line_number":127,"context_line":"execution might be delegated to a respective mechanism driver"},{"line_number":128,"context_line":"(e.g. openvswitch) and from there to agents via RPC calls. The checks at the"},{"line_number":129,"context_line":"lowest level (agent in this case) should be straightforward and should not"},{"line_number":130,"context_line":"aggregate results of other checks. This is to keep complexity of"},{"line_number":131,"context_line":"troubleshooting in high-level checks and have the low-level checks provide only"},{"line_number":132,"context_line":"diagnostics, i.e. description of the actual state compared to expected state."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_aa7c86ec","line":129,"in_reply_to":"1aa78d24_47480d8b","updated":"2016-07-21 11:36:01.000000000","message":"Correct. This is implementation detail as the RPC call (from driver to agent) can include either such a high-level checks aggregating results of some low-level checks, or the RPC call can allow passing in request to execute several checks at once.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":134,"context_line":"In the first iterations, scenarios for port health and port reachability"},{"line_number":135,"context_line":"(both on port resource) in ML2 core plugin with OVS driver, and floating IP"},{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_4c3c9bbf","line":137,"updated":"2016-07-09 00:40:55.000000000","message":"What is the difference between port health and port reachability?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":134,"context_line":"In the first iterations, scenarios for port health and port reachability"},{"line_number":135,"context_line":"(both on port resource) in ML2 core plugin with OVS driver, and floating IP"},{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_6d6adfef","line":137,"in_reply_to":"1aa78d24_4c3c9bbf","updated":"2016-07-21 11:36:01.000000000","message":"Port health diagnoses a given port and its low-level resources for existence and correct setup. It does not need any other port to work.\n\nOn the other hand, port reachability tests whether a packet sent from a single port (ICMP or TCP) can reach the other port. It therefore needs another (neutron-managed) port to work.\n\nFor further details, please see descriptions after lines 196 and 203.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":134,"context_line":"In the first iterations, scenarios for port health and port reachability"},{"line_number":135,"context_line":"(both on port resource) in ML2 core plugin with OVS driver, and floating IP"},{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_751b7d81","line":137,"in_reply_to":"bacf61ea_3dd7aec0","updated":"2016-08-18 08:55:52.000000000","message":"I can move this whole paragraph to line 186 then.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":134,"context_line":"In the first iterations, scenarios for port health and port reachability"},{"line_number":135,"context_line":"(both on port resource) in ML2 core plugin with OVS driver, and floating IP"},{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_3dd7aec0","line":137,"in_reply_to":"dada55a8_6d6adfef","updated":"2016-07-29 00:23:19.000000000","message":"ok, since you introduce them for the first time here, perhaps expand on them?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_07da8517","line":139,"updated":"2016-07-14 13:20:02.000000000","message":"I\u0027m not sure if this paragraph has enough detail to be useful. I would either more detail or remove it entirely. Since user vs. admin and RBAC impact the user facing of this feature directly I think it\u0027s worth discussing in the spec phase.\n\nCan you give 1 example of a check that would make sense to a user, and what would be returned in the case of an error that the user could actually do something about?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_efecc7bc","line":139,"in_reply_to":"1aa78d24_07da8517","updated":"2016-07-21 11:36:01.000000000","message":"For example \"Floating IP not correctly associated.\" with detailed admin-only message \"IP address not found on interface qgXYZ\" - the admin can search for reasons why it was not associated but the user can just reassociate.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":136,"context_line":"health will be implemented. Details are given below in Section"},{"line_number":137,"context_line":"`Implemented health checks`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"API will be accessible both to admin and ordinary users. High-level"},{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_394d88c4","line":139,"in_reply_to":"dada55a8_efecc7bc","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"Checks should be documented in sufficient details for users / operators to"},{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_c23fcbb3","line":143,"updated":"2016-07-14 13:20:02.000000000","message":"DocImpact on patches is a means to an end, not the result. Do we have a clear idea where we want to document this feature? I think the network guide is the only home that makes sense for user or admin facing APIs as the only in-tree docs we have are developer facing.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"Checks should be documented in sufficient details for users / operators to"},{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_feaf607a","line":143,"in_reply_to":"1aa78d24_c23fcbb3","updated":"2016-07-21 11:36:01.000000000","message":"Yes, it is networking guide. [1]\n\n[1] http://docs.openstack.org/mitaka/networking-guide/","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":140,"context_line":"health checks will be subject to RBAC. Level of check result detail will"},{"line_number":141,"context_line":"be restricted for ordinary users, see below."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"Checks should be documented in sufficient details for users / operators to"},{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_b90a7877","line":143,"in_reply_to":"dada55a8_feaf607a","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"The health check execution will be invoked by sending a POST request to"},{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_02bd5302","line":147,"updated":"2016-07-14 13:20:02.000000000","message":"Can you put lines 147 to 184 in a new section, something like \u0027API details\u0027? It looks like the content in this section is different than the content before it.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"The health check execution will be invoked by sending a POST request to"},{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_6f37374d","line":147,"in_reply_to":"1aa78d24_02bd5302","updated":"2016-07-21 11:36:01.000000000","message":"Yes, will be in next draft.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":144,"context_line":"be able to use them. Use of ``DocImpact`` flag on patches introducing new"},{"line_number":145,"context_line":"and modifying usage of existing checks is therefore strongly encouraged."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"The health check execution will be invoked by sending a POST request to"},{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_f9d32002","line":147,"in_reply_to":"dada55a8_6f37374d","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"The request body contains the name of the check (scenario) and"},{"line_number":152,"context_line":"parameter values in a JSON map. The format of the request is as follows:"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_ccd24b5b","line":151,"updated":"2016-07-09 00:40:55.000000000","message":"I personally feel that at this stage, this is a needless complication. In other words we should perform all checks as they are available and in other words assuming GETs and NO request bodies instead (see below). That also simplifies the first implementation because we\u0027d avoid worrying about a number of use cases like validation, listing checks available etc.\n\nNow, should we make this more sophisticated as field experience tells us to, we could figure out ways to provide a request body by keeping backward compat, i.e. either expanding the scenario details on the query string or simply bringing in a check profile resource whose ID can be passed on to the GET request to return the health checks for a given resource. That may actually be nicer because a user would avoid to keep rebuilding the request body for any given request.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"The request body contains the name of the check (scenario) and"},{"line_number":152,"context_line":"parameter values in a JSON map. The format of the request is as follows:"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_d970b6a6","line":151,"in_reply_to":"1aa78d24_ccd24b5b","updated":"2016-07-21 11:36:01.000000000","message":"The scenarios are necessary, please see last reply at [1] for reasoning why.\n\nI am afraid that validations will have to be performed anyway. There is no difference in validation for a parameter passed as GET or POST parameter - e.g. checking that the parameter conforms to a UUID or an IP address format needs to be done in either case.\n\nWhere does supposed difference of complexity of implementation come from? AFAIK, the only difference is setting HTTP method to either GET or POST like in [2] but I might be missing something.\n\n[1] https://review.openstack.org/#/c/308973/4/specs/newton/diagnostics.rst@226\n[2] https://review.openstack.org/#/c/322163/1/neutron/api/v2/router.py@111","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"The request body contains the name of the check (scenario) and"},{"line_number":152,"context_line":"parameter values in a JSON map. The format of the request is as follows:"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_b8fdec6f","line":151,"in_reply_to":"bacf61ea_3d084e2d","updated":"2016-08-18 08:55:52.000000000","message":"For the user, regardless of the API details, diagnostics boils down to an osc command, e.g.:\n\n  os port health port-id\n\nWhat usability complexity do you mean?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":148,"context_line":"**health** subroot. The format of the request and subsequent response"},{"line_number":149,"context_line":"is the same for both member and collection URLs."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"The request body contains the name of the check (scenario) and"},{"line_number":152,"context_line":"parameter values in a JSON map. The format of the request is as follows:"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_3d084e2d","line":151,"in_reply_to":"dada55a8_d970b6a6","updated":"2016-07-29 00:23:19.000000000","message":"What I am saying is that the usability complexity you\u0027re introducing is too high. We are coming from \u0027Neutron has no ability to provide troubleshooting information\u0027 to \u0027In order for Neutron to provide troubleshooting information it must be supplied with very complex requests\u0027. As a first step, it would be reasonable to provide simple feedback to the user without him/her having to build complex API requests, and then iterate over time.\n\nRome was not built in a day.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":170,"context_line":"      \"result_field_1\": \"...\","},{"line_number":171,"context_line":"      \"result_field_2\": \"...\","},{"line_number":172,"context_line":"      ..."},{"line_number":173,"context_line":"  }"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_2c0f8fe2","line":173,"updated":"2016-07-09 00:40:55.000000000","message":"shouldn\u0027t this response be a list of dicts?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":170,"context_line":"      \"result_field_1\": \"...\","},{"line_number":171,"context_line":"      \"result_field_2\": \"...\","},{"line_number":172,"context_line":"      ..."},{"line_number":173,"context_line":"  }"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_d0f1e402","line":173,"in_reply_to":"1aa78d24_2c0f8fe2","updated":"2016-07-21 11:36:01.000000000","message":"No, it is a dict because there is only a single scenario verified, and its consolidated results are reported.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":170,"context_line":"      \"result_field_1\": \"...\","},{"line_number":171,"context_line":"      \"result_field_2\": \"...\","},{"line_number":172,"context_line":"      ..."},{"line_number":173,"context_line":"  }"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_2ba7fcaa","line":173,"in_reply_to":"bacf61ea_7847744b","updated":"2016-08-18 08:55:52.000000000","message":"The user can currently specify a single scenario per request. That might be changed in backward-compatible fashion if agreed in the future but is not expected for the initial implementation.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":170,"context_line":"      \"result_field_1\": \"...\","},{"line_number":171,"context_line":"      \"result_field_2\": \"...\","},{"line_number":172,"context_line":"      ..."},{"line_number":173,"context_line":"  }"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_7847744b","line":173,"in_reply_to":"dada55a8_d0f1e402","updated":"2016-07-29 00:23:19.000000000","message":"Can a user specify more scenarios? Would that become a list then? That\u0027s why I fear this API is too complex and people would have a hard time using it correctly.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"},{"line_number":177,"context_line":"code specific to that check, subject to documentation) and a text describing"},{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_4cbf7bfc","line":177,"updated":"2016-07-09 00:40:55.000000000","message":"not sure I understand the difference between err_code and status. Can you provide an example?","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"},{"line_number":177,"context_line":"code specific to that check, subject to documentation) and a text describing"},{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_700c78ed","line":177,"in_reply_to":"1aa78d24_4cbf7bfc","updated":"2016-07-21 11:36:01.000000000","message":"The difference is that err_code does not change with localization while status does, hence err_code is suitable for tools while status for human-readable message describing the error.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"},{"line_number":177,"context_line":"code specific to that check, subject to documentation) and a text describing"},{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_1e0c2a40","line":177,"in_reply_to":"3ac371cc_980e308a","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"},{"line_number":177,"context_line":"code specific to that check, subject to documentation) and a text describing"},{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3ac371cc_980e308a","line":177,"in_reply_to":"bacf61ea_186f58c6","updated":"2016-08-18 08:55:52.000000000","message":"I will add the following text to the last sentence in this paragraph: \", contrary to status code which is not to enable automatic processing by other tools.\"","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The check mandatorily returns only the **err\\_code** and **status**  fields"},{"line_number":176,"context_line":"that describe numeric error code (zero means no error, nonzero is an error"},{"line_number":177,"context_line":"code specific to that check, subject to documentation) and a text describing"},{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_186f58c6","line":177,"in_reply_to":"dada55a8_700c78ed","updated":"2016-07-29 00:23:19.000000000","message":"ok, elaborate in the spec pls.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"The result of the health check might contain check-specific result fields"},{"line_number":182,"context_line":"that would contain details of the results. However, these fields will"},{"line_number":183,"context_line":"only be accessible to admin users. Non-admin users will only see ``err_code``"},{"line_number":184,"context_line":"and ``status`` fields."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_42e75b46","line":181,"updated":"2016-07-14 13:20:02.000000000","message":"I\u0027m not sure if we can make this determination at this point without concrete examples. Perhaps there will be a user-facing check that would need extra, specific information because it would be required information for the user to be able to take corrective actions. I suggest we just remove this paragraph.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":178,"context_line":"corresponding status message (\"No error\" for no error, error message"},{"line_number":179,"context_line":"otherwise). Status message is subject to localization."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"The result of the health check might contain check-specific result fields"},{"line_number":182,"context_line":"that would contain details of the results. However, these fields will"},{"line_number":183,"context_line":"only be accessible to admin users. Non-admin users will only see ``err_code``"},{"line_number":184,"context_line":"and ``status`` fields."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_1057fc58","line":181,"in_reply_to":"1aa78d24_42e75b46","updated":"2016-07-21 11:36:01.000000000","message":"The paragraph is to justify result_field_N fields in the response. One of the responses can be message describing e.g. \"missing device qbr4223213a-12 in namespace qrouter-aaa-bbb-ccc-ddd\" - clearly useful for admin but should not be visible to ordinary user to prevent revealing infrastructure details.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":190,"context_line":"their contents that will be available after completion of this blueprint."},{"line_number":191,"context_line":"Note that the actual contents of the health checks will need to be"},{"line_number":192,"context_line":"constantly improved to catch up with both existing implementation"},{"line_number":193,"context_line":"and new features. The implementation will target ML2 core plugin with"},{"line_number":194,"context_line":"OVS driver (L2 features) and l3_router plugin."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"-  Port health (internal name: ``resource_health`` on ``port`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_823f8386","line":193,"updated":"2016-07-14 13:20:02.000000000","message":"\"The implementation...\" -\u003e \"The initial implementation...\"","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":190,"context_line":"their contents that will be available after completion of this blueprint."},{"line_number":191,"context_line":"Note that the actual contents of the health checks will need to be"},{"line_number":192,"context_line":"constantly improved to catch up with both existing implementation"},{"line_number":193,"context_line":"and new features. The implementation will target ML2 core plugin with"},{"line_number":194,"context_line":"OVS driver (L2 features) and l3_router plugin."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"-  Port health (internal name: ``resource_health`` on ``port`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_30e1609b","line":193,"in_reply_to":"1aa78d24_823f8386","updated":"2016-07-21 11:36:01.000000000","message":"Will be included in next draft","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":190,"context_line":"their contents that will be available after completion of this blueprint."},{"line_number":191,"context_line":"Note that the actual contents of the health checks will need to be"},{"line_number":192,"context_line":"constantly improved to catch up with both existing implementation"},{"line_number":193,"context_line":"and new features. The implementation will target ML2 core plugin with"},{"line_number":194,"context_line":"OVS driver (L2 features) and l3_router plugin."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"-  Port health (internal name: ``resource_health`` on ``port`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_beb41e82","line":193,"in_reply_to":"dada55a8_30e1609b","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":196,"context_line":"-  Port health (internal name: ``resource_health`` on ``port`` resource)"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"   This layer-2 check verifies that a port has been created, plugged into"},{"line_number":199,"context_line":"   a bridge, and properly set up in the bridge. Further, it verifies that"},{"line_number":200,"context_line":"   DHCP configuration contains proper entries this port. Future work"},{"line_number":201,"context_line":"   should cover firewall rules as well."},{"line_number":202,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_2c582ffa","line":199,"updated":"2016-07-09 00:40:55.000000000","message":"Correctly layer 2 connectivity, and most recently DHCP setup is something that can be inferred by the port STATUS attribute already, so I see some redundancy here. What\u0027s more interesting IMO would be reachability tests to well known resources, e.g. the subnet gateway or (later on) a user given port.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":196,"context_line":"-  Port health (internal name: ``resource_health`` on ``port`` resource)"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"   This layer-2 check verifies that a port has been created, plugged into"},{"line_number":199,"context_line":"   a bridge, and properly set up in the bridge. Further, it verifies that"},{"line_number":200,"context_line":"   DHCP configuration contains proper entries this port. Future work"},{"line_number":201,"context_line":"   should cover firewall rules as well."},{"line_number":202,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_701f586c","line":199,"in_reply_to":"1aa78d24_2c582ffa","updated":"2016-07-21 11:36:01.000000000","message":"Diagnostics is inherently about providing redundant information. If we could rely on status fields of individual resources, diagnostics would not be necessary at all. It is failures in the runtime that should be revealed by comparing of what is expected to be set to what really is set.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":213,"context_line":"   +\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":214,"context_line":"   | ``target_port`` | UUID     | Specifies target port                      |"},{"line_number":215,"context_line":"   +-----------------+----------+--------------------------------------------+"},{"line_number":216,"context_line":"   | ``tcp_port``    | integer  | When set, test is performed whether the    |"},{"line_number":217,"context_line":"   |                 |          | given TCP port is open instead of ping     |"},{"line_number":218,"context_line":"   |                 |          | check.                                     |"},{"line_number":219,"context_line":"   +-----------------+----------+--------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_0c5bb3f7","line":216,"updated":"2016-07-09 00:40:55.000000000","message":"not sure if we should turn the Neutron API into a port scanner.\n\nI would personally limit the check to assessing that security rules are enforced.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":213,"context_line":"   +\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":214,"context_line":"   | ``target_port`` | UUID     | Specifies target port                      |"},{"line_number":215,"context_line":"   +-----------------+----------+--------------------------------------------+"},{"line_number":216,"context_line":"   | ``tcp_port``    | integer  | When set, test is performed whether the    |"},{"line_number":217,"context_line":"   |                 |          | given TCP port is open instead of ping     |"},{"line_number":218,"context_line":"   |                 |          | check.                                     |"},{"line_number":219,"context_line":"   +-----------------+----------+--------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_79c42a3f","line":216,"in_reply_to":"1aa78d24_0c5bb3f7","updated":"2016-07-21 11:36:01.000000000","message":"Consider a guest that only communicates via ssh and otherwise does not respond to any traffic including icmp. Now, the problematic part would be in unsuccessful assignment of floating IP, hence the user would not be able to test the host from external network. How would the user be able to test that the host is accessible at least from internal network?\n\nWe should offer user way to check whether a host with disabled ping is reachable with e.g. ssh or http. If it turns out to be a security issue, it is always possible to limit number of usages of this check per tenant to a reasonable number per time slot (e.g. 3 times in a minute).","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"1dfa5551267d657451dc790e6bfd5c8827520840","unresolved":false,"context_lines":[{"line_number":213,"context_line":"   +\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":214,"context_line":"   | ``target_port`` | UUID     | Specifies target port                      |"},{"line_number":215,"context_line":"   +-----------------+----------+--------------------------------------------+"},{"line_number":216,"context_line":"   | ``tcp_port``    | integer  | When set, test is performed whether the    |"},{"line_number":217,"context_line":"   |                 |          | given TCP port is open instead of ping     |"},{"line_number":218,"context_line":"   |                 |          | check.                                     |"},{"line_number":219,"context_line":"   +-----------------+----------+--------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_2b3edcc0","line":216,"in_reply_to":"bacf61ea_f8cd24b8","updated":"2016-08-18 08:55:52.000000000","message":"No, I mean checking security group rules and their proper setup, and checking whether the ssh port is open at the instance. The user could have set a wrong security group that prohibits (according to this example) the ssh traffic so the latter check would pass while the former would fail.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"90ae0ec2e74ea0a09af7e8fe2a8a9989824d2aeb","unresolved":false,"context_lines":[{"line_number":213,"context_line":"   +\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":214,"context_line":"   | ``target_port`` | UUID     | Specifies target port                      |"},{"line_number":215,"context_line":"   +-----------------+----------+--------------------------------------------+"},{"line_number":216,"context_line":"   | ``tcp_port``    | integer  | When set, test is performed whether the    |"},{"line_number":217,"context_line":"   |                 |          | given TCP port is open instead of ping     |"},{"line_number":218,"context_line":"   |                 |          | check.                                     |"},{"line_number":219,"context_line":"   +-----------------+----------+--------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bacf61ea_f8cd24b8","line":216,"in_reply_to":"dada55a8_79c42a3f","updated":"2016-07-29 00:23:19.000000000","message":"You mean the guest itself has a local firewall that blocks certain ports?\n\nI am not sure I understand what you\u0027re saying. From the platform standpoint we should ensure that the infrastructure is in place, e.g. the security rules are applied, tunnels are setup etc. Now assume that a security rule allows telnet and the guest has telnet disabled; that\u0027s a guest issue, the users can troubleshoot it themselves, the platform can\u0027t introspect the guest (or at least we should not assume it can)","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"801445d233bd1c50b507a25d0c2f0b3460a59d6f","unresolved":false,"context_lines":[{"line_number":221,"context_line":"   The reachability of the ports can only be tested if the two ports"},{"line_number":222,"context_line":"   are assigned IP addresses of the same IP version. The source"},{"line_number":223,"context_line":"   and target ports need to be either from the same network or"},{"line_number":224,"context_line":"   two networks directly interconnected by a router."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"-  Validation of floating IP address (internal name: ``resource_health`` on"},{"line_number":227,"context_line":"   ``floating-ip`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_fa2f1e3c","line":224,"updated":"2016-07-08 10:47:24.000000000","message":"I would note that, the security group of the port will be inspected to make sure that the tcp_port / icmp is going to be accepted, and otherwise provide a meaningful message explaining that the security group does not allow it.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":221,"context_line":"   The reachability of the ports can only be tested if the two ports"},{"line_number":222,"context_line":"   are assigned IP addresses of the same IP version. The source"},{"line_number":223,"context_line":"   and target ports need to be either from the same network or"},{"line_number":224,"context_line":"   two networks directly interconnected by a router."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"-  Validation of floating IP address (internal name: ``resource_health`` on"},{"line_number":227,"context_line":"   ``floating-ip`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_90012c08","line":224,"in_reply_to":"1aa78d24_fa2f1e3c","updated":"2016-07-21 11:36:01.000000000","message":"Thanks, that will be included in the next draft.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":221,"context_line":"   The reachability of the ports can only be tested if the two ports"},{"line_number":222,"context_line":"   are assigned IP addresses of the same IP version. The source"},{"line_number":223,"context_line":"   and target ports need to be either from the same network or"},{"line_number":224,"context_line":"   two networks directly interconnected by a router."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"-  Validation of floating IP address (internal name: ``resource_health`` on"},{"line_number":227,"context_line":"   ``floating-ip`` resource)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_9e191ada","line":224,"in_reply_to":"dada55a8_90012c08","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"801445d233bd1c50b507a25d0c2f0b3460a59d6f","unresolved":false,"context_lines":[{"line_number":227,"context_line":"   ``floating-ip`` resource)"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   This check validates that the floating IP has been set on the appropriate"},{"line_number":230,"context_line":"   router interface and port association is properly configured."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Changes in OpenStack CLI"},{"line_number":233,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_da9ea262","line":230,"updated":"2016-07-08 10:47:24.000000000","message":"We could also have floating-ip reachability by creating a port on the external network, with a temporarily allocated external IP address that pings / connects to tcp_port of the floating-ip.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":227,"context_line":"   ``floating-ip`` resource)"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"   This check validates that the floating IP has been set on the appropriate"},{"line_number":230,"context_line":"   router interface and port association is properly configured."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Changes in OpenStack CLI"},{"line_number":233,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_b9ca2219","line":230,"in_reply_to":"1aa78d24_da9ea262","updated":"2016-07-21 11:36:01.000000000","message":"Yes, this would be possible, it is actually reachability scenario for floating IP. Hence it would be best implemented after the three checks described above are already in place - this would then be a straightforward extension.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":240,"context_line":"+------------+--------------------------------------+"},{"line_number":241,"context_line":"| Syntax:    | os **port health** *UUID*            |"},{"line_number":242,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":243,"context_line":"| Maps to:   | POST /v2/ports/*UUID*/\\ **health**   |"},{"line_number":244,"context_line":"+------------+--------------------------------------+"},{"line_number":245,"context_line":"| Scenario:  | ``resource_health``                  |"},{"line_number":246,"context_line":"+------------+--------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_6cf997c8","line":243,"updated":"2016-07-09 00:40:55.000000000","message":"see my comment above. Line 151","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":248,"context_line":"Diagnostics of floating IP health:"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"+------------+---------------------------------------------+"},{"line_number":251,"context_line":"| Syntax:    | os **ip floating health** *UUID*            |"},{"line_number":252,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":253,"context_line":"| Maps to:   | POST /v2/floating-ips/*UUID*/\\ **health**   |"},{"line_number":254,"context_line":"+------------+---------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_62e097fb","line":251,"updated":"2016-07-14 13:20:02.000000000","message":"I suggest we offer a \u0027UUID or IP address\u0027 format where the CLI will accept both a UUID of a FIP as well as an IP address.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":248,"context_line":"Diagnostics of floating IP health:"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"+------------+---------------------------------------------+"},{"line_number":251,"context_line":"| Syntax:    | os **ip floating health** *UUID*            |"},{"line_number":252,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":253,"context_line":"| Maps to:   | POST /v2/floating-ips/*UUID*/\\ **health**   |"},{"line_number":254,"context_line":"+------------+---------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_59e04696","line":251,"in_reply_to":"1aa78d24_62e097fb","updated":"2016-07-21 11:36:01.000000000","message":"Will be included in next draft.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"d2a7008be7ab8fc6d88dee97deff8698372f6fe7","unresolved":false,"context_lines":[{"line_number":248,"context_line":"Diagnostics of floating IP health:"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"+------------+---------------------------------------------+"},{"line_number":251,"context_line":"| Syntax:    | os **ip floating health** *UUID*            |"},{"line_number":252,"context_line":"+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":253,"context_line":"| Maps to:   | POST /v2/floating-ips/*UUID*/\\ **health**   |"},{"line_number":254,"context_line":"+------------+---------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a89bdaa_c3b2ef05","line":251,"in_reply_to":"dada55a8_59e04696","updated":"2016-09-07 11:47:45.000000000","message":"Done","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"801445d233bd1c50b507a25d0c2f0b3460a59d6f","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"2. *Server-side implementation of health checks:* implementation of"},{"line_number":282,"context_line":"   the aforementioned health checks. The changes are going to happen"},{"line_number":283,"context_line":"   in existing agents, no new \"health\" agent is going to be developed."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"3. *OpenStack client changes:* enhance CLI with commands to invoke"},{"line_number":286,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_1a2aeae7","line":283,"updated":"2016-07-08 10:47:24.000000000","message":"While I understand that some of the scenarios (health) will fit better existing agents, may be reachability scenarios can be done in a separate agent.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"74043d16b51821b805e981ec21357a258ce8a6e9","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"2. *Server-side implementation of health checks:* implementation of"},{"line_number":282,"context_line":"   the aforementioned health checks. The changes are going to happen"},{"line_number":283,"context_line":"   in existing agents, no new \"health\" agent is going to be developed."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"3. *OpenStack client changes:* enhance CLI with commands to invoke"},{"line_number":286,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_308707d9","line":283,"in_reply_to":"1aa78d24_1a2aeae7","updated":"2016-07-08 11:26:04.000000000","message":"Another point for a separate agent in the case of reachability scenarios, it that other drivers using common technologies as OVS/LB could  optionally leverage this implementation as-is without any addition to their agents.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"750ad752bee44471f5fcd49431aaee05c12b9f13","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"2. *Server-side implementation of health checks:* implementation of"},{"line_number":282,"context_line":"   the aforementioned health checks. The changes are going to happen"},{"line_number":283,"context_line":"   in existing agents, no new \"health\" agent is going to be developed."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"3. *OpenStack client changes:* enhance CLI with commands to invoke"},{"line_number":286,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_cc2ecb41","line":283,"in_reply_to":"1aa78d24_308707d9","updated":"2016-07-09 00:40:55.000000000","message":"I would agree. I think whether we use existing agents or not depends on what the check actually looks like. Avoiding to deploy yet another service is definitely a compelling proposition.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":19797,"name":"Hynek Mlnarik","email":"hmlnarik@redhat.com","username":"hmlnarik"},"change_message_id":"62b80091064c3900c01d4d353b07c32e38e2f62d","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"2. *Server-side implementation of health checks:* implementation of"},{"line_number":282,"context_line":"   the aforementioned health checks. The changes are going to happen"},{"line_number":283,"context_line":"   in existing agents, no new \"health\" agent is going to be developed."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"3. *OpenStack client changes:* enhance CLI with commands to invoke"},{"line_number":286,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dada55a8_397bd2c2","line":283,"in_reply_to":"1aa78d24_510f2b88","updated":"2016-07-21 11:36:01.000000000","message":"I agree with Assaf. Another agent would also bring another potential point of failure.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"d8857057a5e585a11db9117d1f348817ed625b12","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"2. *Server-side implementation of health checks:* implementation of"},{"line_number":282,"context_line":"   the aforementioned health checks. The changes are going to happen"},{"line_number":283,"context_line":"   in existing agents, no new \"health\" agent is going to be developed."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"3. *OpenStack client changes:* enhance CLI with commands to invoke"},{"line_number":286,"context_line":"   diagnostics API."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1aa78d24_510f2b88","line":283,"in_reply_to":"1aa78d24_cc2ecb41","updated":"2016-07-14 13:20:02.000000000","message":"We can have code reuse without a new agent. I understand the appeal of not doing any invasive code changes to existing agents, on the other hand a new agent would require changes to all deployment tools out there and would lower the usage of this new feature. Without the requirement of a new agent, the new functionality should be available to all deployments out of the box without any configuration file changes which makes things a magnitude of order simpler.","commit_id":"4aeab5d6f89fa2208d7b902c0db5d9fc06ad4935"}],"specs/ocata/diagnostics.rst":[{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"20e8889d568b61782fa4246e265bb64a40ea2b49","unresolved":false,"context_lines":[{"line_number":47,"context_line":"diagnostics of Neutron ``subnets``, similar to the reference implementation"},{"line_number":48,"context_line":"suggested in [6]_. These not only serve as a reference implementation, but"},{"line_number":49,"context_line":"also help diagnose issues with Neutron DHCP enabled subnets when consumed"},{"line_number":50,"context_line":"by a knowledge operator or higher-level tool."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"As to the standardization of diagnostic data points in Neutron; this spec"},{"line_number":53,"context_line":"(by void) proposes such topics be addressed in future workings after this"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a74a57a_be3bdd9b","line":50,"range":{"start_line":50,"start_character":5,"end_line":50,"end_character":14},"updated":"2016-11-22 23:25:05.000000000","message":"knowledgeable","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"20e8889d568b61782fa4246e265bb64a40ea2b49","unresolved":false,"context_lines":[{"line_number":50,"context_line":"by a knowledge operator or higher-level tool."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"As to the standardization of diagnostic data points in Neutron; this spec"},{"line_number":53,"context_line":"(by void) proposes such topics be addressed in future workings after this"},{"line_number":54,"context_line":"initial plumbing has had time to run in the wild. Instead, this spec proposes"},{"line_number":55,"context_line":"a basic JSON map to transport free-from JSON based diagnostic key/value pairs."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a74a57a_7eeea5ed","line":53,"range":{"start_line":53,"start_character":54,"end_line":53,"end_character":62},"updated":"2016-11-22 23:25:05.000000000","message":"work","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"20e8889d568b61782fa4246e265bb64a40ea2b49","unresolved":false,"context_lines":[{"line_number":52,"context_line":"As to the standardization of diagnostic data points in Neutron; this spec"},{"line_number":53,"context_line":"(by void) proposes such topics be addressed in future workings after this"},{"line_number":54,"context_line":"initial plumbing has had time to run in the wild. Instead, this spec proposes"},{"line_number":55,"context_line":"a basic JSON map to transport free-from JSON based diagnostic key/value pairs."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"The primary use cases this spec seeks to address are:"},{"line_number":58,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a74a57a_5ec80975","line":55,"range":{"start_line":55,"start_character":35,"end_line":55,"end_character":39},"updated":"2016-11-22 23:25:05.000000000","message":"form","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"20e8889d568b61782fa4246e265bb64a40ea2b49","unresolved":false,"context_lines":[{"line_number":98,"context_line":"database table in a new column ``diagnostic_resource_types``. This column"},{"line_number":99,"context_line":"stores a JSON formatted list of resource_types the agent provides data"},{"line_number":100,"context_line":"for. None (default) or an empty list signifies the agent does not provide"},{"line_number":101,"context_line":"and diagnostic data and thus will not be called to service a diagnostic"},{"line_number":102,"context_line":"request. Neutron (OVO) objects will be updated as necessary."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"REST API"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a74a57a_bb1ccf78","line":101,"range":{"start_line":101,"start_character":0,"end_line":101,"end_character":3},"updated":"2016-11-22 23:25:05.000000000","message":"any","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"53f40d589cab29e2afe043c8aa7a6a0c9680ac45","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"    GET /v2.0/{resource}/{resource_id}/diagnostics"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"The response is a list of diagnostic (dict) objects; one object per"},{"line_number":116,"context_line":"diagnostic provider invoked during data collection. Each diagnostic"},{"line_number":117,"context_line":"object contains a few key/value pairs reflecting the state/status of"},{"line_number":118,"context_line":"the diagnostic provider invocation, as well as a ``data`` key who\u0027s"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3a71b18c_0086c7b8","line":115,"updated":"2016-12-02 23:49:52.000000000","message":"A flat list of dict may become messy. Imagine a subnet and its diagnostic information. DHCP is one part that can go wrong, there\u0027s DNS, the Gateway, security rules, etc. I think providers should be grouped by \u0027type\u0027, e.g. the nature of the resource whose state they are supplying.\n\nOn the other end, I feel this modeling becomes plugin dependent. How would a look to:\n\n GET /v2.0/subnets/315ec9bb-34f5-4f7a-a44c-b13015a26803/diagnostics\n\nLook like for a plugin that does not implement DHCP services with agents? Or even where pluggable IPAM is involved?\n\nWhile I appreciate this approach sounds compelling for its simplicity, I fear that its simplicity will make the API somewhat usable by developers only, or people who have an incredibly intimate knowledge of the inner workings of neutron (the many variations of it anyway).\n\nI was hoping we could take this effort as an opportunity to elevate the level of abstraction of information provided by the diagnostics API in such a way that it\u0027d be plugin agnostic.\n\nFor instance, when it comes to DHCP, all solutions  need a DHCP service, that\u0027s active and participating in DHCP protocol communications, it does not strictly matters where this service runs and how it\u0027s implemented, until things go wrong, of course, when a user is looking for remedy actions and/or clues to hand over to more trained people.\n\nI don\u0027t see this in the proposed approach. It would be nice if we can codify ERROR codes (e.g. E44: your DHCP service is not responding to pings), potential root causes (e.g. R23: your DHCP service NAK the request), and/or mitigations action (M22: disable/re-enable dhcp on your subnet) etc. and at the same time move away from the underlying implementation details for the supplied providers, I think this would genuinely lead to a more usable and easier to understand API.","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"20e8889d568b61782fa4246e265bb64a40ea2b49","unresolved":false,"context_lines":[{"line_number":182,"context_line":"Diagnostic Provider Registration"},{"line_number":183,"context_line":"--------------------------------"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"The mechanism in which a source registers as a diagnostic provider depends on"},{"line_number":186,"context_line":"the source itself. For this spec we cover both Neutron plugins and agents."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Plugins that provide diagnostic data can be discovered via Neutron manager"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a74a57a_be511d11","line":185,"range":{"start_line":185,"start_character":14,"end_line":185,"end_character":16},"updated":"2016-11-22 23:25:05.000000000","message":"by","commit_id":"8c6e65911368a5b4b6cdf96c50de5dfdbe8cae7c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"5e8ef1178c6c4c14b11f8a0c17c76874b2a1f48d","unresolved":false,"context_lines":[{"line_number":47,"context_line":"This registration, along with runtime data (e.g. is the agent active),"},{"line_number":48,"context_line":"can be used to service a diagnostic data request for a given resource."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The sample pseudo code below exemplifies the flow:"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"#. API request for diagnostics of resource ``X`` with ID ``Y``."},{"line_number":53,"context_line":"#. API controller discovers all registered/active diagnostic providers."}],"source_content_type":"text/x-rst","patch_set":8,"id":"ba5201f7_9217b850","line":50,"updated":"2016-12-30 23:29:10.000000000","message":"It would be helpful to include in this pseudo code the steps to discover and execute the checks. That will help reviewers / readers to understand better the relationship between diagnostics providers and checks","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"52cb35fc7705ffdb163316d69f94777cbfc2b5c0","unresolved":false,"context_lines":[{"line_number":47,"context_line":"This registration, along with runtime data (e.g. is the agent active),"},{"line_number":48,"context_line":"can be used to service a diagnostic data request for a given resource."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The sample pseudo code below exemplifies the flow:"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"#. API request for diagnostics of resource ``X`` with ID ``Y``."},{"line_number":53,"context_line":"#. API controller discovers all registered/active diagnostic providers."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa31d9ce_0b904494","line":50,"in_reply_to":"ba5201f7_9217b850","updated":"2017-02-15 22:49:55.000000000","message":"The latest PS has many changes; can you please see if its more clear.","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"5e8ef1178c6c4c14b11f8a0c17c76874b2a1f48d","unresolved":false,"context_lines":[{"line_number":82,"context_line":"database table in a new column ``diagnostic_resource_types``. This column"},{"line_number":83,"context_line":"stores a JSON formatted list of resource_types the agent provides data"},{"line_number":84,"context_line":"for. None (default) or an empty list signifies the agent does not provide"},{"line_number":85,"context_line":"and diagnostic data and thus will not be called to service a diagnostic"},{"line_number":86,"context_line":"request. Neutron (OVO) objects will be updated as necessary."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"The diagnostic framework will also contain in-memory discovery/caching of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"ba5201f7_127f48ab","line":85,"range":{"start_line":85,"start_character":0,"end_line":85,"end_character":3},"updated":"2016-12-30 23:29:10.000000000","message":"I think we need to remove this","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"52cb35fc7705ffdb163316d69f94777cbfc2b5c0","unresolved":false,"context_lines":[{"line_number":82,"context_line":"database table in a new column ``diagnostic_resource_types``. This column"},{"line_number":83,"context_line":"stores a JSON formatted list of resource_types the agent provides data"},{"line_number":84,"context_line":"for. None (default) or an empty list signifies the agent does not provide"},{"line_number":85,"context_line":"and diagnostic data and thus will not be called to service a diagnostic"},{"line_number":86,"context_line":"request. Neutron (OVO) objects will be updated as necessary."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"The diagnostic framework will also contain in-memory discovery/caching of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa31d9ce_ebdbf079","line":85,"range":{"start_line":85,"start_character":0,"end_line":85,"end_character":3},"in_reply_to":"ba5201f7_127f48ab","updated":"2017-02-15 22:49:55.000000000","message":"Done","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"5e8ef1178c6c4c14b11f8a0c17c76874b2a1f48d","unresolved":false,"context_lines":[{"line_number":113,"context_line":"return a ``remediation`` to describe potential ways to remediate the failed"},{"line_number":114,"context_line":"check."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"The ``status`` as the diagnostic level is handled by the framework and"},{"line_number":117,"context_line":"can be one of the following:"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- ``OK``: All checks for the diagnostic are successful."}],"source_content_type":"text/x-rst","patch_set":8,"id":"ba5201f7_b513c65b","line":116,"range":{"start_line":116,"start_character":15,"end_line":116,"end_character":17},"updated":"2016-12-30 23:29:10.000000000","message":"at?","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"52cb35fc7705ffdb163316d69f94777cbfc2b5c0","unresolved":false,"context_lines":[{"line_number":113,"context_line":"return a ``remediation`` to describe potential ways to remediate the failed"},{"line_number":114,"context_line":"check."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"The ``status`` as the diagnostic level is handled by the framework and"},{"line_number":117,"context_line":"can be one of the following:"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- ``OK``: All checks for the diagnostic are successful."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa31d9ce_8b40b408","line":116,"range":{"start_line":116,"start_character":15,"end_line":116,"end_character":17},"in_reply_to":"ba5201f7_b513c65b","updated":"2017-02-15 22:49:55.000000000","message":"Done","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"5e8ef1178c6c4c14b11f8a0c17c76874b2a1f48d","unresolved":false,"context_lines":[{"line_number":120,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":121,"context_line":"- ``INACTIVE``: One or more providers is inactivate and couldn\u0027t be invoked"},{"line_number":122,"context_line":"  to run the diagnostic checks."},{"line_number":123,"context_line":"- ``DEGRADED``: Checks can register be optional. If a check is optional and"},{"line_number":124,"context_line":"  fails or is ``INACTIVE`` the diagnostic status will be ``DEGRADED``."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"For example::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"ba5201f7_9525e2ac","line":123,"range":{"start_line":123,"start_character":36,"end_line":123,"end_character":38},"updated":"2016-12-30 23:29:10.000000000","message":"to be?","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"52cb35fc7705ffdb163316d69f94777cbfc2b5c0","unresolved":false,"context_lines":[{"line_number":120,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":121,"context_line":"- ``INACTIVE``: One or more providers is inactivate and couldn\u0027t be invoked"},{"line_number":122,"context_line":"  to run the diagnostic checks."},{"line_number":123,"context_line":"- ``DEGRADED``: Checks can register be optional. If a check is optional and"},{"line_number":124,"context_line":"  fails or is ``INACTIVE`` the diagnostic status will be ``DEGRADED``."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"For example::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa31d9ce_ab43b811","line":123,"range":{"start_line":123,"start_character":36,"end_line":123,"end_character":38},"in_reply_to":"ba5201f7_9525e2ac","updated":"2017-02-15 22:49:55.000000000","message":"Done","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"5e8ef1178c6c4c14b11f8a0c17c76874b2a1f48d","unresolved":false,"context_lines":[{"line_number":224,"context_line":"The default access control is ``admin_only``, but operators can change this"},{"line_number":225,"context_line":"in ``policy.json`` as needed."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Diagnostic Provider Checks"},{"line_number":228,"context_line":"--------------------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"The framework will provide both a plugin server-side and an agent-side extension"}],"source_content_type":"text/x-rst","patch_set":8,"id":"ba5201f7_d565aae1","line":227,"updated":"2016-12-30 23:29:10.000000000","message":"Maybe add here more detail as to how the checks are discovered and executed by the diagnostic providers","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"52cb35fc7705ffdb163316d69f94777cbfc2b5c0","unresolved":false,"context_lines":[{"line_number":224,"context_line":"The default access control is ``admin_only``, but operators can change this"},{"line_number":225,"context_line":"in ``policy.json`` as needed."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Diagnostic Provider Checks"},{"line_number":228,"context_line":"--------------------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"The framework will provide both a plugin server-side and an agent-side extension"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa31d9ce_0fa4bb05","line":227,"in_reply_to":"ba5201f7_d565aae1","updated":"2017-02-15 22:49:55.000000000","message":"Please see latest PS.","commit_id":"2f9315bcd954d84e52517b94c76a0a72de48c320"}],"specs/pike/diagnostics.rst":[{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":18,"context_line":"tools [3]_, out-of-tree plugin utilities [4]_, etc. that could all benefit from"},{"line_number":19,"context_line":"additional Neutron diagnostic data APIs. And while we certainly don\u0027t want"},{"line_number":20,"context_line":"Neutron to become a new diagnostic system, other projects [5]_ have"},{"line_number":21,"context_line":"found value in exposing some level diagnostic data for users (typically"},{"line_number":22,"context_line":"operators) needing to reach under the hood."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"By the same token; Neutron offers a broad array of resources backed by a"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_a3a016a7","line":21,"range":{"start_line":21,"start_character":35,"end_line":21,"end_character":45},"updated":"2017-02-18 00:58:24.000000000","message":"of diagnostic...","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":18,"context_line":"tools [3]_, out-of-tree plugin utilities [4]_, etc. that could all benefit from"},{"line_number":19,"context_line":"additional Neutron diagnostic data APIs. And while we certainly don\u0027t want"},{"line_number":20,"context_line":"Neutron to become a new diagnostic system, other projects [5]_ have"},{"line_number":21,"context_line":"found value in exposing some level diagnostic data for users (typically"},{"line_number":22,"context_line":"operators) needing to reach under the hood."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"By the same token; Neutron offers a broad array of resources backed by a"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_28c40091","line":21,"range":{"start_line":21,"start_character":35,"end_line":21,"end_character":45},"in_reply_to":"da36d5c6_a3a016a7","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":21,"context_line":"found value in exposing some level diagnostic data for users (typically"},{"line_number":22,"context_line":"operators) needing to reach under the hood."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"By the same token; Neutron offers a broad array of resources backed by a"},{"line_number":25,"context_line":"heterogeneous set of technologies. As a result, standardizing a set of"},{"line_number":26,"context_line":"concrete diagnostics across this diverse domain is no simple task."},{"line_number":27,"context_line":"Moreover, a Neutron resource may be realized through multiple components"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_4392fa58","line":24,"range":{"start_line":24,"start_character":17,"end_line":24,"end_character":18},"updated":"2017-02-18 00:58:24.000000000","message":"I think this should be a comma","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":21,"context_line":"found value in exposing some level diagnostic data for users (typically"},{"line_number":22,"context_line":"operators) needing to reach under the hood."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"By the same token; Neutron offers a broad array of resources backed by a"},{"line_number":25,"context_line":"heterogeneous set of technologies. As a result, standardizing a set of"},{"line_number":26,"context_line":"concrete diagnostics across this diverse domain is no simple task."},{"line_number":27,"context_line":"Moreover, a Neutron resource may be realized through multiple components"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_68bef800","line":24,"range":{"start_line":24,"start_character":17,"end_line":24,"end_character":18},"in_reply_to":"da36d5c6_4392fa58","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Diagnostic checks are effectively small plugins that provide the following:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"- Check specific metadata including the check\u0027s name, description, is required,"},{"line_number":59,"context_line":"  as well as a set of resource types (``ports``, ``networks``, etc.) the check"},{"line_number":60,"context_line":"  is applicable to."},{"line_number":61,"context_line":"- The actual diagnostic check logic. This logic will be invoked when collecting"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_83ef92af","line":58,"range":{"start_line":58,"start_character":67,"end_line":58,"end_character":78},"updated":"2017-02-18 00:58:24.000000000","message":"This is confusing. Did you try to say is required attribute?","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Diagnostic checks are effectively small plugins that provide the following:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"- Check specific metadata including the check\u0027s name, description, is required,"},{"line_number":59,"context_line":"  as well as a set of resource types (``ports``, ``networks``, etc.) the check"},{"line_number":60,"context_line":"  is applicable to."},{"line_number":61,"context_line":"- The actual diagnostic check logic. This logic will be invoked when collecting"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_28cec083","line":58,"range":{"start_line":58,"start_character":67,"end_line":58,"end_character":78},"in_reply_to":"da36d5c6_83ef92af","updated":"2017-02-28 17:02:01.000000000","message":"I broke this into a sublist and tried to describe better in new PS.","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  If a check supports multiple resource types, its implementation can key off"},{"line_number":66,"context_line":"  the resource type that\u0027ll be passed in by the framework."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As part of this work a sample check will be provided for both a sever and"},{"line_number":69,"context_line":"agent side plugin that illustrates how to use the framework."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Diagnostic Providers"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_0311e2ac","line":68,"range":{"start_line":68,"start_character":64,"end_line":68,"end_character":69},"updated":"2017-02-18 00:58:24.000000000","message":"server","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  If a check supports multiple resource types, its implementation can key off"},{"line_number":66,"context_line":"  the resource type that\u0027ll be passed in by the framework."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As part of this work a sample check will be provided for both a sever and"},{"line_number":69,"context_line":"agent side plugin that illustrates how to use the framework."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Diagnostic Providers"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_a8a0f0a6","line":68,"range":{"start_line":68,"start_character":64,"end_line":68,"end_character":69},"in_reply_to":"da36d5c6_0311e2ac","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"As part of this work a sample check will be provided for both a sever and"},{"line_number":69,"context_line":"agent side plugin that illustrates how to use the framework."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Diagnostic Providers"},{"line_number":72,"context_line":"--------------------"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Diagnostic providers are simply \u0027sources\u0027 for diagnostic checks and contain"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_be2aed7c","line":71,"updated":"2017-02-18 00:58:24.000000000","message":"Sooner or later someone is going to ask how this is going to support agentless plugins / drivers like OVN. I think it would be better if we start answering that question now. One idea that comes to mind is in that case, the agentless plugin / driver has to provide a method in its API where the diagnostics frameworks can query the resources and checks that can be performed.","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":68,"context_line":"As part of this work a sample check will be provided for both a sever and"},{"line_number":69,"context_line":"agent side plugin that illustrates how to use the framework."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Diagnostic Providers"},{"line_number":72,"context_line":"--------------------"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Diagnostic providers are simply \u0027sources\u0027 for diagnostic checks and contain"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_a8dc7019","line":71,"in_reply_to":"da36d5c6_be2aed7c","updated":"2017-02-28 17:02:01.000000000","message":"I added some language in the next PS. Let me know if you think it\u0027s clear enough.","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":93,"context_line":"APIs can get a reference to the plugin instance via neutron manager."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The neutron agent based diagnostic provider binding delivered by this"},{"line_number":96,"context_line":"implementation will use the agent extension framework; plumbing the support"},{"line_number":97,"context_line":"for all neutron based agents. However since the agent binding is remote to the"},{"line_number":98,"context_line":"neutron API server it has the following notable differences:"},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_23542653","line":96,"range":{"start_line":96,"start_character":53,"end_line":96,"end_character":54},"updated":"2017-02-18 00:58:24.000000000","message":"I think this should be a comma","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":93,"context_line":"APIs can get a reference to the plugin instance via neutron manager."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The neutron agent based diagnostic provider binding delivered by this"},{"line_number":96,"context_line":"implementation will use the agent extension framework; plumbing the support"},{"line_number":97,"context_line":"for all neutron based agents. However since the agent binding is remote to the"},{"line_number":98,"context_line":"neutron API server it has the following notable differences:"},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_8846ccbd","line":96,"range":{"start_line":96,"start_character":53,"end_line":96,"end_character":54},"in_reply_to":"da36d5c6_23542653","updated":"2017-02-28 17:02:01.000000000","message":"I\u0027m pretty sure you can use \u0027;\u0027 just about anywhere, but I prefer it here since its a continuation.","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":133,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"As mentioned previously, neutron agent based diagnostic providers report"},{"line_number":136,"context_line":"the resource types the checks the manage support. This is a list of"},{"line_number":137,"context_line":"unique string resource types that is transported in a new key/value of"},{"line_number":138,"context_line":"the agent state report. This list is stored in the agent database table"},{"line_number":139,"context_line":"in a new column called ``diagnostic_resource_types``."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_c3c0aae3","line":136,"range":{"start_line":136,"start_character":34,"end_line":136,"end_character":40},"updated":"2017-02-18 00:58:24.000000000","message":"manager?","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":133,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"As mentioned previously, neutron agent based diagnostic providers report"},{"line_number":136,"context_line":"the resource types the checks the manage support. This is a list of"},{"line_number":137,"context_line":"unique string resource types that is transported in a new key/value of"},{"line_number":138,"context_line":"the agent state report. This list is stored in the agent database table"},{"line_number":139,"context_line":"in a new column called ``diagnostic_resource_types``."}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_a878f0f9","line":136,"range":{"start_line":136,"start_character":34,"end_line":136,"end_character":40},"in_reply_to":"da36d5c6_c3c0aae3","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"    GET /v2.0/{resource}/{resource_id}/diagnostics"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The response is a list of diagnostic (dict) objects; one object per"},{"line_number":178,"context_line":"``diagnostic``. A diagnostic is an aspect of the ``{resource}`` checked,"},{"line_number":179,"context_line":"and contains a ``description`` as well as a diagnostic ``status`` object"},{"line_number":180,"context_line":"and list of individual ``checks`` run for the said diagnostic. Diagnostic"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_8355d21e","line":177,"range":{"start_line":177,"start_character":51,"end_line":177,"end_character":52},"updated":"2017-02-18 00:58:24.000000000","message":"comma","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"    GET /v2.0/{resource}/{resource_id}/diagnostics"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The response is a list of diagnostic (dict) objects; one object per"},{"line_number":178,"context_line":"``diagnostic``. A diagnostic is an aspect of the ``{resource}`` checked,"},{"line_number":179,"context_line":"and contains a ``description`` as well as a diagnostic ``status`` object"},{"line_number":180,"context_line":"and list of individual ``checks`` run for the said diagnostic. Diagnostic"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_a85f1074","line":177,"range":{"start_line":177,"start_character":51,"end_line":177,"end_character":52},"in_reply_to":"da36d5c6_8355d21e","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The array of ``checks`` returned for each diagnostic includes high level"},{"line_number":185,"context_line":"details about the check such as ``name``, ``description`` and ``provider``."},{"line_number":186,"context_line":"In addition, check\u0027s report their own ``status`` based on the result of"},{"line_number":187,"context_line":"their check execution. If a check is not successful, the check must"},{"line_number":188,"context_line":"return a ``remediation`` to describe potential ways to remediate the failed"},{"line_number":189,"context_line":"check."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_a3301609","line":186,"range":{"start_line":186,"start_character":13,"end_line":186,"end_character":20},"updated":"2017-02-18 00:58:24.000000000","message":"checks","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"The array of ``checks`` returned for each diagnostic includes high level"},{"line_number":185,"context_line":"details about the check such as ``name``, ``description`` and ``provider``."},{"line_number":186,"context_line":"In addition, check\u0027s report their own ``status`` based on the result of"},{"line_number":187,"context_line":"their check execution. If a check is not successful, the check must"},{"line_number":188,"context_line":"return a ``remediation`` to describe potential ways to remediate the failed"},{"line_number":189,"context_line":"check."}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_28540053","line":186,"range":{"start_line":186,"start_character":13,"end_line":186,"end_character":20},"in_reply_to":"da36d5c6_a3301609","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"- ``OK``: All checks for the diagnostic are successful."},{"line_number":195,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":196,"context_line":"- ``INACTIVE``: One or more providers is inactivate and couldn\u0027t be invoked"},{"line_number":197,"context_line":"  to run the diagnostic checks."},{"line_number":198,"context_line":"- ``DEGRADED``: Checks can registered as optional. If a check is optional and"},{"line_number":199,"context_line":"  fails, or is ``INACTIVE``, the diagnostic status will be ``DEGRADED``."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_632ffea1","line":196,"range":{"start_line":196,"start_character":41,"end_line":196,"end_character":51},"updated":"2017-02-18 00:58:24.000000000","message":"\"inactive\".","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"- ``OK``: All checks for the diagnostic are successful."},{"line_number":195,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":196,"context_line":"- ``INACTIVE``: One or more providers is inactivate and couldn\u0027t be invoked"},{"line_number":197,"context_line":"  to run the diagnostic checks."},{"line_number":198,"context_line":"- ``DEGRADED``: Checks can registered as optional. If a check is optional and"},{"line_number":199,"context_line":"  fails, or is ``INACTIVE``, the diagnostic status will be ``DEGRADED``."}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_884b2cb0","line":196,"range":{"start_line":196,"start_character":41,"end_line":196,"end_character":51},"in_reply_to":"da36d5c6_632ffea1","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"dd38fc06ee746128a367f8ed1f346e0b5cb8e75b","unresolved":false,"context_lines":[{"line_number":304,"context_line":"--------"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"While the main purpose of this effort is to spearhead diagnostics in Neutron and"},{"line_number":307,"context_line":"start building out the plumbing, this functionality is immediately valuable by"},{"line_number":308,"context_line":"consumers and out-of-tree plugins alike."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"For example:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da36d5c6_43375ae3","line":307,"range":{"start_line":307,"start_character":76,"end_line":307,"end_character":78},"updated":"2017-02-18 00:58:24.000000000","message":"for","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"b1197a0bbc0d3cfbe7250649a02321eb6735bd98","unresolved":false,"context_lines":[{"line_number":304,"context_line":"--------"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"While the main purpose of this effort is to spearhead diagnostics in Neutron and"},{"line_number":307,"context_line":"start building out the plumbing, this functionality is immediately valuable by"},{"line_number":308,"context_line":"consumers and out-of-tree plugins alike."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"For example:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"ba2be162_e8d028cc","line":307,"range":{"start_line":307,"start_character":76,"end_line":307,"end_character":78},"in_reply_to":"da36d5c6_43375ae3","updated":"2017-02-28 17:02:01.000000000","message":"Done","commit_id":"b0e2aa56f987ae5c3bb481c3ebec81979d0afc7e"},{"author":{"_account_id":17120,"name":"Manjeet Singh Bhatia","email":"manjeet.s.bhatia@intel.com","username":"manjeets"},"change_message_id":"e73654d8af5bef9ff5dd0bc170fdff50d6d7b63e","unresolved":false,"context_lines":[{"line_number":88,"context_line":"  sections."},{"line_number":89,"context_line":"- An internal cache of loaded checks and public APIs to:"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"  - Determine if the provider has a check for a given resource type."},{"line_number":92,"context_line":"  - List the resource types the provider has checks for."},{"line_number":93,"context_line":"  - Execute all checks applicable to a specified resource type and resource"},{"line_number":94,"context_line":"    instance, collect the well-formed results and return them."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The neutron server diagnostic provider binding delivered by this effort"},{"line_number":97,"context_line":"will be implemented as a service plugin; consumers wishing to invoke it\u0027s"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_b3f82a4b","line":94,"range":{"start_line":91,"start_character":1,"end_line":94,"end_character":62},"updated":"2017-03-01 18:31:44.000000000","message":"isn\u0027t the case is missing here if a check involves multiple resources ??","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"ddcbf849d82c157fdeac310fd68cb9692e4f92dc","unresolved":false,"context_lines":[{"line_number":88,"context_line":"  sections."},{"line_number":89,"context_line":"- An internal cache of loaded checks and public APIs to:"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"  - Determine if the provider has a check for a given resource type."},{"line_number":92,"context_line":"  - List the resource types the provider has checks for."},{"line_number":93,"context_line":"  - Execute all checks applicable to a specified resource type and resource"},{"line_number":94,"context_line":"    instance, collect the well-formed results and return them."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The neutron server diagnostic provider binding delivered by this effort"},{"line_number":97,"context_line":"will be implemented as a service plugin; consumers wishing to invoke it\u0027s"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_fa44b14a","line":94,"range":{"start_line":91,"start_character":1,"end_line":94,"end_character":62},"in_reply_to":"ba2be162_b3f82a4b","updated":"2017-03-03 20:59:22.000000000","message":"IMHO that\u0027s getting into impl details, but OK I\u0027ll add it.","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":17120,"name":"Manjeet Singh Bhatia","email":"manjeet.s.bhatia@intel.com","username":"manjeets"},"change_message_id":"e73654d8af5bef9ff5dd0bc170fdff50d6d7b63e","unresolved":false,"context_lines":[{"line_number":98,"context_line":"APIs can get a reference to the plugin instance via neutron manager. In"},{"line_number":99,"context_line":"addition, other plugins can act as a diagnostic provider by supporting"},{"line_number":100,"context_line":"the extension and implementing the respective diagnostic methods required."},{"line_number":101,"context_line":"This approach will work for agent-less plugins and mimics what\u0027s typically"},{"line_number":102,"context_line":"done today in such plugins when supporting extensions in their implementation."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"The neutron agent based diagnostic provider binding delivered by this"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_d34afe82","line":101,"range":{"start_line":101,"start_character":13,"end_line":101,"end_character":24},"updated":"2017-03-01 18:31:44.000000000","message":"will also work ?","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"ddcbf849d82c157fdeac310fd68cb9692e4f92dc","unresolved":false,"context_lines":[{"line_number":98,"context_line":"APIs can get a reference to the plugin instance via neutron manager. In"},{"line_number":99,"context_line":"addition, other plugins can act as a diagnostic provider by supporting"},{"line_number":100,"context_line":"the extension and implementing the respective diagnostic methods required."},{"line_number":101,"context_line":"This approach will work for agent-less plugins and mimics what\u0027s typically"},{"line_number":102,"context_line":"done today in such plugins when supporting extensions in their implementation."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"The neutron agent based diagnostic provider binding delivered by this"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_5a469d4f","line":101,"range":{"start_line":101,"start_character":13,"end_line":101,"end_character":24},"in_reply_to":"ba2be162_d34afe82","updated":"2017-03-03 20:59:22.000000000","message":"Done","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":17120,"name":"Manjeet Singh Bhatia","email":"manjeet.s.bhatia@intel.com","username":"manjeets"},"change_message_id":"e73654d8af5bef9ff5dd0bc170fdff50d6d7b63e","unresolved":false,"context_lines":[{"line_number":204,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":205,"context_line":"- ``INACTIVE``: One or more providers is inactive and couldn\u0027t be invoked"},{"line_number":206,"context_line":"  to run the diagnostic checks."},{"line_number":207,"context_line":"- ``DEGRADED``: Checks can registered as optional. If a check is optional and"},{"line_number":208,"context_line":"  fails, or is ``INACTIVE``, the diagnostic status will be ``DEGRADED``."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"For example::"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_e49bbac7","line":207,"range":{"start_line":207,"start_character":16,"end_line":207,"end_character":27},"updated":"2017-03-01 18:31:44.000000000","message":"Checks can be","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"ddcbf849d82c157fdeac310fd68cb9692e4f92dc","unresolved":false,"context_lines":[{"line_number":204,"context_line":"- ``ERROR``: One or more checks failed."},{"line_number":205,"context_line":"- ``INACTIVE``: One or more providers is inactive and couldn\u0027t be invoked"},{"line_number":206,"context_line":"  to run the diagnostic checks."},{"line_number":207,"context_line":"- ``DEGRADED``: Checks can registered as optional. If a check is optional and"},{"line_number":208,"context_line":"  fails, or is ``INACTIVE``, the diagnostic status will be ``DEGRADED``."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"For example::"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba2be162_3a62c9d8","line":207,"range":{"start_line":207,"start_character":16,"end_line":207,"end_character":27},"in_reply_to":"ba2be162_e49bbac7","updated":"2017-03-03 20:59:22.000000000","message":"Done","commit_id":"071c341d13bbca769e5773bb9f2f5dc10e990c36"},{"author":{"_account_id":17120,"name":"Manjeet Singh Bhatia","email":"manjeet.s.bhatia@intel.com","username":"manjeets"},"change_message_id":"0aa0f0828a2dc5da32d84b49f822e0c11b45eb6f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"1a1ced50_532f67a0","updated":"2017-03-22 16:13:18.000000000","message":"This is looking good, but what i think missing is info about cli, would some initiator commands be added too ? or that\u0027s out of scope for this spec ?","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7e87b2c7411bace0abd289828db0d55f9f6a86aa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"bff0334d_0a5d5879","in_reply_to":"1a1ced50_532f67a0","updated":"2017-04-07 16:34:27.000000000","message":"I was thinking the CLI could come later after the API solidifies a bit. I added some wording to this effect in order to clarify.","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"eba16f6f2c381ddc8b1a1fb50cddabf919628b07","unresolved":false,"context_lines":[{"line_number":133,"context_line":"  This is just as it sounds; statically have a list of checks in the code"},{"line_number":134,"context_line":"  rather than dynamically discovering + loading."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Each approach above has it\u0027s pros/cons. For the initial implementation we"},{"line_number":137,"context_line":"suggest using the last approach of statically defining the checks in the code."},{"line_number":138,"context_line":"While this is not the most robust approach, it minimizes complexity and allows"},{"line_number":139,"context_line":"us to get a tire-kicker more rapidly that we can then later iterate on once"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a1ced50_a5301509","line":136,"updated":"2017-03-16 21:20:50.000000000","message":"+1 for starting out without plugin framework while we stabilize on an internal API for these","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"eba16f6f2c381ddc8b1a1fb50cddabf919628b07","unresolved":false,"context_lines":[{"line_number":146,"context_line":"the resource types the checks they manage support. This is a list of"},{"line_number":147,"context_line":"unique string resource types that is transported in a new key/value of"},{"line_number":148,"context_line":"the agent state report. This list is stored in the agent database table"},{"line_number":149,"context_line":"in a new column called ``diagnostic_resource_types``."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"None (default) or an empty list signifies the agent does not provide"},{"line_number":152,"context_line":"diagnostic data and thus will not be called to service a diagnostic"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a1ced50_c53511f8","line":149,"updated":"2017-03-16 21:20:50.000000000","message":"nit: in the DB this should probably be a separate table with a relationship to the agent table since it\u0027s a 1-to-many relationship","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7e87b2c7411bace0abd289828db0d55f9f6a86aa","unresolved":false,"context_lines":[{"line_number":146,"context_line":"the resource types the checks they manage support. This is a list of"},{"line_number":147,"context_line":"unique string resource types that is transported in a new key/value of"},{"line_number":148,"context_line":"the agent state report. This list is stored in the agent database table"},{"line_number":149,"context_line":"in a new column called ``diagnostic_resource_types``."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"None (default) or an empty list signifies the agent does not provide"},{"line_number":152,"context_line":"diagnostic data and thus will not be called to service a diagnostic"}],"source_content_type":"text/x-rst","patch_set":12,"id":"bff0334d_aa466c20","line":149,"in_reply_to":"1a1ced50_c53511f8","updated":"2017-04-07 16:34:27.000000000","message":"I changed the wording... Was thinking we could hash through this on the patch review.","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"eba16f6f2c381ddc8b1a1fb50cddabf919628b07","unresolved":false,"context_lines":[{"line_number":172,"context_line":"  type, invoke their API(s) to run the checks they know about for the said"},{"line_number":173,"context_line":"  resource type and resource instance."},{"line_number":174,"context_line":"- Collect the diagnostic results, roll them into a nice response and return"},{"line_number":175,"context_line":"  them to the caller."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"REST API"},{"line_number":178,"context_line":"--------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a1ced50_e53a0de7","line":175,"updated":"2017-03-16 21:20:50.000000000","message":"These diagnostics responses could be quite slow and I\u0027m concerned about blocking waiting for the response (taking up HTTP connections and generally just being a slow API experience). Is it possible to have /diagnostics just return the last diagnostic run result. Then allow users to POST to /diagnostics or something to trigger a new back-ground refresh task to populate with new results?\n\nThis will mean storing the results in a big diag_results column for each resource of course.","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"7e87b2c7411bace0abd289828db0d55f9f6a86aa","unresolved":false,"context_lines":[{"line_number":172,"context_line":"  type, invoke their API(s) to run the checks they know about for the said"},{"line_number":173,"context_line":"  resource type and resource instance."},{"line_number":174,"context_line":"- Collect the diagnostic results, roll them into a nice response and return"},{"line_number":175,"context_line":"  them to the caller."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"REST API"},{"line_number":178,"context_line":"--------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"bff0334d_aacc2c61","line":175,"in_reply_to":"1a1ced50_e53a0de7","updated":"2017-04-07 16:34:27.000000000","message":"I totally agree with your point.\n\nHowever after I started thinking about how this might look (submitting a BG job to run the diagnostic collection), I feel like it becomes overly complex for an initial iteration. Unless I\u0027m missing something, we\u0027d likely then need to also store to data about the actual BG job, and potentially be able to handle job state (e.g. was running collection, but was killed during). In addition, this is an admin-only \"debug\" API which (to some degree) implies to me stuff is probably already not working properly, so perhaps some of the concerns about clogging up the API before less relevant in this context?\n\n\nOverall, I feel like it\u0027s in our best interest to proceed with something simple to see if there\u0027s any adopoters and reiterate based on their needs and real-life uses.\n\n\nAm I over thinking this; do you have a simple idea in mind for something async?","commit_id":"d2be0d06744853b7089d7d0402ce2161e22c943f"}]}