)]}'
{"specs/train/approved/server-status-unknown-if-host-status-unknown.rst":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a2fdf33129cae6a6730e1e01013ac2f0c606c0bf","unresolved":false,"context_lines":[{"line_number":30,"context_line":"and frustrating experience when they try to work with their server, when the"},{"line_number":31,"context_line":"status indicates it is ACTIVE and it is not usable."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"In nova, we can know when compute host status is UNKNOWN by querying the"},{"line_number":34,"context_line":"``servicegroup.API``. We could call ``servicegroup.API.service_is_up`` and if"},{"line_number":35,"context_line":"it returns False, we show the server status as UNKNOWN."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use Cases"},{"line_number":38,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_60ad4fe9","line":35,"range":{"start_line":33,"start_character":0,"end_line":35,"end_character":55},"updated":"2019-06-18 22:50:19.000000000","message":"Question: I actually wasn\u0027t sure whether to do it this way vs calling the get_instance_host_status API [1] and showing UNKNOWN if host status is UNKNOWN. Yet another option is showing UNKNOWN if host status !\u003d UP. With host_status !\u003d UP, I was concerned whether that could be considered leaking hypervisor details because host_status can also be DOWN, MAINTENANCE, or NONE.\n\nAnyone have any opinion on what\u0027s the best way?\n\n[1] https://github.com/openstack/nova/blob/fa37cf2/nova/compute/api.py#L4814","commit_id":"285bdf803e9492a644c083378f5de0eb77e0d2c7"},{"author":{"_account_id":10905,"name":"Erik McCormick","email":"emccormickva@gmail.com","username":"emccormickva"},"change_message_id":"65d05019762de71222fa2b4516001c433d752272","unresolved":false,"context_lines":[{"line_number":30,"context_line":"and frustrating experience when they try to work with their server, when the"},{"line_number":31,"context_line":"status indicates it is ACTIVE and it is not usable."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"In nova, we can know when compute host status is UNKNOWN by querying the"},{"line_number":34,"context_line":"``servicegroup.API``. We could call ``servicegroup.API.service_is_up`` and if"},{"line_number":35,"context_line":"it returns False, we show the server status as UNKNOWN."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use Cases"},{"line_number":38,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_a097c73a","line":35,"range":{"start_line":33,"start_character":0,"end_line":35,"end_character":55},"in_reply_to":"9fb8cfa7_60ad4fe9","updated":"2019-06-19 00:32:56.000000000","message":"Without knowledge of other information about the host, I\u0027m not sure what the harm of leaking the status of said host via instance status would be. I would actually rather explicitly look for HostStatus.DOWN rather than !\u003d UP. Being in maintenance does not imply any instance issues. It simply implies that no new instances can be scheduled there.","commit_id":"285bdf803e9492a644c083378f5de0eb77e0d2c7"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"91f2f5664dc0ab62e633d9492c9ceb0617a10a30","unresolved":false,"context_lines":[{"line_number":30,"context_line":"and frustrating experience when they try to work with their server, when the"},{"line_number":31,"context_line":"status indicates it is ACTIVE and it is not usable."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"In nova, we can know when compute host status is UNKNOWN by querying the"},{"line_number":34,"context_line":"``servicegroup.API``. We could call ``servicegroup.API.service_is_up`` and if"},{"line_number":35,"context_line":"it returns False, we show the server status as UNKNOWN."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use Cases"},{"line_number":38,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_5509e6da","line":35,"range":{"start_line":33,"start_character":0,"end_line":35,"end_character":55},"in_reply_to":"9fb8cfa7_a097c73a","updated":"2019-06-19 06:08:54.000000000","message":"Yeah, good point. I came to the same conclusion after thinking about it more (that, for example, MAINTENANCE doesn\u0027t necessarily mean disruption to the instance). So probably best not to show UNKNOWN for MAINTENANCE and the other states.\n\nI just pushed a new PS that proposes showing server status UNKNOWN when service_is_up !\u003d True. None of the other statuses available via the get_instance_host_status method (MAINTENANCE, [forced] DOWN, or NONE) necessarily imply anything about the instance\u0027s status.","commit_id":"285bdf803e9492a644c083378f5de0eb77e0d2c7"},{"author":{"_account_id":10905,"name":"Erik McCormick","email":"emccormickva@gmail.com","username":"emccormickva"},"change_message_id":"a4380539ea1f7249f7acb8f5ec4bac26c7f3e760","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``get_instance_host_status`` is only"},{"line_number":114,"context_line":"called when policy ``show:host_status`` is allowed for the given request"},{"line_number":115,"context_line":"context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_c1d8b380","line":116,"updated":"2019-06-19 14:46:19.000000000","message":"Could some of the performance impact be mitigated by only calling get_instance_host_status if the instance status is ACTIVE? If Nova has already definitively declared the instance as SHUTOFF or ERROR that would seem to indicate that we\u0027re not in an UNKNOWN state.","commit_id":"285bdf803e9492a644c083378f5de0eb77e0d2c7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"52a9b8ea203cfc376f2c3e129ce2949d39cd078f","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Use Cases"},{"line_number":38,"context_line":"---------"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"As an End User, I want to have some idea when my server might not be usable"},{"line_number":41,"context_line":"because of underlying infrastructure issues. Seeing server status as ACTIVE"},{"line_number":42,"context_line":"while not being able to access my server is a confusing and frustrating"},{"line_number":43,"context_line":"experience."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"As an Operator, I want end users to open fewer support tickets because of"},{"line_number":46,"context_line":"confusion when trying to access servers showing status as ACTIVE while"},{"line_number":47,"context_line":"underlying infrastructure problems are occurring."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"},{"line_number":50,"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":2,"id":"9fb8cfa7_7076a10f","line":47,"range":{"start_line":40,"start_character":0,"end_line":47,"end_character":49},"updated":"2019-07-02 22:08:27.000000000","message":"the flip side of both of these is if the instance is actually fine but the operator is just doing maintenance  on the compute agent this might confuse  end users who can still actully ssh into the instance but can not manage it.\n\nsince instance can be running when they are in an unknown state that may result in more support tickets during some maintenance operations as the end user expect it to be active.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"52a9b8ea203cfc376f2c3e129ce2949d39cd078f","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"We propose to use a new compute API microversion to begin showing server status"},{"line_number":53,"context_line":"as UNKNOWN when corresponding host status is UNKNOWN. Showing server status"},{"line_number":54,"context_line":"as UNKNOWN should be safe in not leaking underlying hypervisor details and will"},{"line_number":55,"context_line":"have the benefit of allowing end users to see an accurate status for their"},{"line_number":56,"context_line":"servers."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_9064754b","line":54,"range":{"start_line":54,"start_character":26,"end_line":54,"end_character":70},"updated":"2019-07-02 22:08:27.000000000","message":"maybe. it is leaking the fact the nova compute agent is not currently managing the instance on that host or that it is but something is preventing the control plane from talking ot the compute agent on that host.\n\nif this was admin only be defualt then i totally would agree.\nim not sure this is enough of a leak for me to be concerned we are leaking info however so im more meh on the implication of this chagne in behavior.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8144c1014ef9d9b928358653688ee50c21a497c1","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The proposal is to show the server status as UNKNOWN at the REST API layer"},{"line_number":59,"context_line":"only and will not actually set the instance.vm_state field to UNKNOWN. So, the"},{"line_number":60,"context_line":"instance record in the database will never be set to status UNKNOWN and"},{"line_number":61,"context_line":"notifications will similarly not change. This behavior is similar to the way"},{"line_number":62,"context_line":"that server status is shown as UNKNOWN with `down cells support`_ when a cell"},{"line_number":63,"context_line":"is down."},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_78dc0846","line":61,"updated":"2019-06-20 07:39:44.000000000","message":"This also means that all the server operations that is allowed on ACTIVE instance will be allowed on UNKNOWN instance as well. Or vica versa operations that are not allowed on ACTIVE instance (like start) will not be allowed on UNKNOWN instance.\n\nThis leads to a minor issue with error messages like:\n\n  $ openstack server start my-vm\n  Cannot \u0027start\u0027 instance 57a74a07-ffb4-44d8-b9b6- \n  11c74551baa7 while it is in vm_state active (HTTP 409) \n  (Request-ID: req-2f0af0e7-64aa-4866-a03d-0f2157c2603c)\n\nas it will still talk about ACTIVE instance even if the instance is previously reported as UNKNOWN.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"52a9b8ea203cfc376f2c3e129ce2949d39cd078f","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The proposal is to show the server status as UNKNOWN at the REST API layer"},{"line_number":59,"context_line":"only and will not actually set the instance.vm_state field to UNKNOWN. So, the"},{"line_number":60,"context_line":"instance record in the database will never be set to status UNKNOWN and"},{"line_number":61,"context_line":"notifications will similarly not change. This behavior is similar to the way"},{"line_number":62,"context_line":"that server status is shown as UNKNOWN with `down cells support`_ when a cell"},{"line_number":63,"context_line":"is down."},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_30e7c9af","line":61,"in_reply_to":"9fb8cfa7_2567e4b9","updated":"2019-07-02 22:08:27.000000000","message":"personally as a non admin i think the only instnace operation we shoudl support for unknow instace is delete.\n\nas an admin i can see attpemting other operation but i dont think we should attpemt other operations for non admin users.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8a8b590821495af1ee23b624ffbba0f72d0a1e02","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The proposal is to show the server status as UNKNOWN at the REST API layer"},{"line_number":59,"context_line":"only and will not actually set the instance.vm_state field to UNKNOWN. So, the"},{"line_number":60,"context_line":"instance record in the database will never be set to status UNKNOWN and"},{"line_number":61,"context_line":"notifications will similarly not change. This behavior is similar to the way"},{"line_number":62,"context_line":"that server status is shown as UNKNOWN with `down cells support`_ when a cell"},{"line_number":63,"context_line":"is down."},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_e08fc42b","line":61,"in_reply_to":"9fb8cfa7_78dc0846","updated":"2019-06-21 17:04:38.000000000","message":"Yes, that is true. I am imagining that users would be OK with the inconsistency if it means they get some hint about real instance status instead of always ACTIVE when possibly not really active.\n\nHere\u0027s a link to the code where UNKNOWN is similarly used for down cell support:\n\nhttps://github.com/openstack/nova/blob/1ca69e8/nova/api/openstack/compute/views/servers.py#L150","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The proposal is to show the server status as UNKNOWN at the REST API layer"},{"line_number":59,"context_line":"only and will not actually set the instance.vm_state field to UNKNOWN. So, the"},{"line_number":60,"context_line":"instance record in the database will never be set to status UNKNOWN and"},{"line_number":61,"context_line":"notifications will similarly not change. This behavior is similar to the way"},{"line_number":62,"context_line":"that server status is shown as UNKNOWN with `down cells support`_ when a cell"},{"line_number":63,"context_line":"is down."},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_e1d0e1f9","line":61,"in_reply_to":"9fb8cfa7_e08fc42b","updated":"2019-06-26 20:45:36.000000000","message":"I have a feeling this will become a slippery slope because someone will fail to heed any warning about UNKNOWN, try something with the server and it will work - or not - and they\u0027ll be confused and still complain and want us to do more validation when checking instance state in the API when performing some operation because the view builder said it was UNKNOWN.\n\nSimilarly I could see notification consumers saying they want the same kind of UNKNOWN status sent in notifications. Note that we don\u0027t reflect host_status in the instance notifications today so notification consumers really don\u0027t have any alternatives.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The proposal is to show the server status as UNKNOWN at the REST API layer"},{"line_number":59,"context_line":"only and will not actually set the instance.vm_state field to UNKNOWN. So, the"},{"line_number":60,"context_line":"instance record in the database will never be set to status UNKNOWN and"},{"line_number":61,"context_line":"notifications will similarly not change. This behavior is similar to the way"},{"line_number":62,"context_line":"that server status is shown as UNKNOWN with `down cells support`_ when a cell"},{"line_number":63,"context_line":"is down."},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_2567e4b9","line":61,"in_reply_to":"9fb8cfa7_e1d0e1f9","updated":"2019-06-26 21:27:31.000000000","message":"I guess I don\u0027t see it that way because to me, this proposal is a best effort don\u0027t-boil-the-ocean attempt to be more transparent to users. A small effort to improve server status from a cosmetic standpoint. I suppose we could worry about whether if we give an inch, will people want to take a mile later, but I wasn\u0027t thinking about it that way.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":68,"context_line":"------------"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The only other alternative for observing an accurate status when host status is"},{"line_number":71,"context_line":"UNKNOWN is to look at the ``host_status`` field itself. The ``host_status``"},{"line_number":72,"context_line":"field for server details API is opt-in via the ``--fields`` option in the"},{"line_number":73,"context_line":"python-novaclient CLI and is controlled by a policy configuration that defaults"},{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_c1a59da0","line":73,"range":{"start_line":71,"start_character":56,"end_line":73,"end_character":21},"updated":"2019-06-26 20:45:36.000000000","message":"This is a pretty weak argument IMO, there are any number of client-side libraries out there. Also, are you only talking about server list here? Because \"nova show\" with the proper microversion and auth should show the host_status in the detailed output for a given server.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":68,"context_line":"------------"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The only other alternative for observing an accurate status when host status is"},{"line_number":71,"context_line":"UNKNOWN is to look at the ``host_status`` field itself. The ``host_status``"},{"line_number":72,"context_line":"field for server details API is opt-in via the ``--fields`` option in the"},{"line_number":73,"context_line":"python-novaclient CLI and is controlled by a policy configuration that defaults"},{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_c54da872","line":73,"range":{"start_line":71,"start_character":56,"end_line":73,"end_character":21},"in_reply_to":"9fb8cfa7_c1a59da0","updated":"2019-06-26 21:27:31.000000000","message":"Yes, talking about server list here -- I missed mentioning the context.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"ecb64da0f338eb415552ef389ef61461c15d7638","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_4037b0b1","line":77,"updated":"2019-06-21 16:58:55.000000000","message":"If you took the policy route and just let operators supply their own override and keep the API locked down to system users by default, you could filter things accordingly in the nova API [0]. Since you have a context object, you should be able to determine the difference in users. Example policy:\n\n  \"os_compute_api:servers:show:host_status\": \"(role:reader and system_scope:all) or (role:reader and target.project_id)\"\n\n[0] https://pasted.tech/pastes/d7363625b6f8b52d68b6ab9515f8e796cb989e66.raw","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e83d1de521a57d2b21c150dfefe945b239111107","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_37099f94","line":77,"in_reply_to":"9fb8cfa7_205f1c73","updated":"2019-06-21 19:43:01.000000000","message":"Sure - you\u0027ll just to overload the policy stuff a little bit. You could do something like:\n\n  \"os_compute_api:servers:show:host_status\": \"role:operator or (role:reader and target.project_id)\"\n\nYou\u0027d need to adjust the logic in the nova API to check for a special role name [0]. It\u0027s probably not as clean as the system-specific approach though...\n\n[0] https://pasted.tech/pastes/191423e7b910a47b545768d194554ab362cd1045.raw","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2c095d6466e80b0192a8a77c4d23253c475c6743","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_3798bf19","line":77,"in_reply_to":"9fb8cfa7_37099f94","updated":"2019-06-21 20:02:20.000000000","message":"Oh, duh. Thanks. We already have a \u0027context.is_admin\u0027 that \u003d\u003d \u0027role:admin\u0027 essentially. So after checking policy, we could just check context.is_admin before showing all host_status... but then no one could configure non-admin to see host_status if they wanted to allow that.\n\nEven if it were possible to get finer grain here (guess we could by adding another policy rule), we have a customer ask essentially to not \"lie\" about the server status being ACTIVE if we know the host status to be UNKNOWN.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_c1411da8","line":77,"in_reply_to":"9fb8cfa7_3798bf19","updated":"2019-06-26 20:45:36.000000000","message":"\u003e Even if it were possible to get finer grain here (guess we could by adding another policy rule), we have a customer ask essentially to not \"lie\" about the server status being ACTIVE if we know the host status to be UNKNOWN.\n\nWhat about power_state and probably other parts of the API related to the server that are based on compute service level information?\n\nI think Dan mentioned this in the ML thread but if we\u0027re going to return the status as UNKNOWN then we likely need to go all the way and only return the partial response like in the down cell case and assume we can\u0027t even read information out of the cell database so you\u0027re just going to get basic information from the pieces we can pull out of the API DB.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ace1175dc3b3fb7d769191c4871b0fb1630def97","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_205f1c73","line":77,"in_reply_to":"9fb8cfa7_4037b0b1","updated":"2019-06-21 17:18:11.000000000","message":"Thanks, that is interesting. That code block is imagining what\u0027s possible in the future, when nova is no longer using the \u0027admin\u0027 role to signify an admin user, yeah?\n\nIIUC, that isn\u0027t possible today, in a world where end users do not request system-scoped tokens and instead use the \u0027admin\u0027 role to auth as admin/system. A user with the \u0027admin\u0027 role would have context.project_id set to something, right? So in that code block, they would only be able to see UNKNOWN and not all the possible host_status.\n\nI\u0027m just trying to determine whether we can do something similar to what you describe in the old-school way today or not.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"52a9b8ea203cfc376f2c3e129ce2949d39cd078f","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_904eb594","line":77,"in_reply_to":"9fb8cfa7_85a1f0f9","updated":"2019-07-02 22:08:27.000000000","message":"as a customer that has an sla with a cloud provider where if an instance is not active i get competation for the downtime to i get compenstaion for an instance in the unkonw state?\n\nas a normal user will i be billed for it?\n\nexposing unknown to an unprivileged end-user has business impacts. if i was offering a production service and i had a cloud native app i proable want to kill it and deploy another instance just as i would if the server was in error.\n\nbut in the same case if i have such an app i likely have a monitroing system deployed and can tell that already because my app has not phoned home in x secons or maybe it has an i know its actully still active.\n\nso yes this could be usefult but im not sure i want normal users to be able to see the unknown state by defualt. i like controlling it by policy and defualting to admin only as i think this is generally a useful thing.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":74,"context_line":"to admin-only. The ``host_status`` field can show status of UNKNOWN but can"},{"line_number":75,"context_line":"also reveal status of UP (heartbeat is fresh) and DOWN (forced_down for"},{"line_number":76,"context_line":"maintenance) which are details the operator may not want to expose to end"},{"line_number":77,"context_line":"users."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Data model impact"},{"line_number":80,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_85a1f0f9","line":77,"in_reply_to":"9fb8cfa7_c1411da8","updated":"2019-06-26 21:27:31.000000000","message":"I guess I don\u0027t understand why we can\u0027t just keep it simple and show something more accurate than ACTIVE in server status as a cosmetic thing for the end user. I was thinking UNKNOWN is a nice hint for the user that other fields might not be accurate -- proceed with caution. Comparing what we have today (always ACTIVE) to what\u0027s proposed, I don\u0027t see how it\u0027s not a small improvement.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":101,"context_line":"---------------------"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"End users will be able to see a server status of UNKNOWN in the /servers REST"},{"line_number":104,"context_line":"API and python-novaclient CLI with the new API microversion when the"},{"line_number":105,"context_line":"corresponding host status is UNKNOWN."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Performance Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_617951fa","line":104,"range":{"start_line":104,"start_character":4,"end_line":104,"end_character":29},"updated":"2019-06-26 20:45:36.000000000","message":"I think this is irrelevant. Long-term we want to move off novaclient and use OSC and by default OSC is going to request 2.1 and so the uninformed user (your customer in this case) won\u0027t even get the UNKNOWN status thing they are looking for (by default anyway). But it could be anything that consumes the API, like ansible, the openstacksdk, etc.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":101,"context_line":"---------------------"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"End users will be able to see a server status of UNKNOWN in the /servers REST"},{"line_number":104,"context_line":"API and python-novaclient CLI with the new API microversion when the"},{"line_number":105,"context_line":"corresponding host status is UNKNOWN."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Performance Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_a57f5464","line":104,"range":{"start_line":104,"start_character":4,"end_line":104,"end_character":29},"in_reply_to":"9fb8cfa7_617951fa","updated":"2019-06-26 21:27:31.000000000","message":"FWIW, our customer isn\u0027t uninformed any longer after we explained how things work today, but they have a fair point \"why show server status as ACTIVE when there\u0027s a way to tell it might not actually be ACTIVE.\" Why willfully show an incorrect status when there\u0027s a way to show that something might be off? That is how they are thinking about it and based on a couple of responses from operators on the ML thread, they think about it the same way too.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":10905,"name":"Erik McCormick","email":"emccormickva@gmail.com","username":"emccormickva"},"change_message_id":"f452c0249c8f30496f1e456b6fc379fa596ffd0e","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_410923db","line":116,"updated":"2019-06-19 14:50:15.000000000","message":"I guess it also helps to comment on the correct patch set...\n\nCould some of the performance impact be mitigated by only calling get_instance_host_status if the instance status is ACTIVE? If Nova has already definitively declared the instance as SHUTOFF or ERROR that would seem to indicate that we\u0027re not in an UNKNOWN state.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"07f859448e8acdc125175dcc10be4099329cf30e","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_612d47a7","line":116,"in_reply_to":"9fb8cfa7_410923db","updated":"2019-06-19 15:22:08.000000000","message":"Yes, I think that\u0027s a good idea and reduces the overall impact.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8d8d34290493f4a46d760ad7384ffd64b29535fa","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_a8a6490e","line":116,"in_reply_to":"9fb8cfa7_45dd386e","updated":"2019-06-26 22:24:55.000000000","message":"I was responding specifically to you seeming to agree with Erik here:\n\n\u003e Yes, I think that\u0027s a good idea and reduces the overall impact.\n\ni.e. only do the service is up UNKNOWN thing if the status would otherwise be ACTIVE.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_c16fdd25","line":116,"in_reply_to":"9fb8cfa7_612d47a7","updated":"2019-06-26 20:45:36.000000000","message":"This is another slippery slope and why I don\u0027t like this proposal. Consider any other number of statuses related the underlying host status:\n\nhttps://developer.openstack.org/api-guide/compute/server_concepts.html#server-status\n\nLike HARD_REBOOT, MIGRATING, PAUSED, SHELVED, VERIFY_RESIZE, etc. Let\u0027s say one of the computes is down when I try to confirm a resize but because the API still showed VERIFY_RESIZE rather than UNKNOWN, now I\u0027m going to open a ticket saying the API shouldn\u0027t \"lie to me\". Then what do we do - have another microversion to handle non-ACTIVE cases as well?","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"bf75d586902cc7170d31244bfada51f99f341f33","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_a8de493b","line":116,"in_reply_to":"9fb8cfa7_a8a6490e","updated":"2019-06-26 22:36:43.000000000","message":"\u003e I was responding specifically to you seeming to agree with Erik\n \u003e here:\n \u003e \n \u003e \u003e Yes, I think that\u0027s a good idea and reduces the overall impact.\n \u003e \n \u003e i.e. only do the service is up UNKNOWN thing if the status would\n \u003e otherwise be ACTIVE.\n\nOh, sorry, yes I was agreeing with him. But when you brought up the other possible server statuses, I\u0027m not sure it would be the right move to pick and choose which get translated to UNKNOWN. It seemed to make sense that ERROR state could be left as-is because it\u0027s a terminal state, but thinking about all of the others, it\u0027s probably best to just show any as UNKNOWN if not service_is_up.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":113,"context_line":"expensive than current default where ``service_is_up`` is only called (by way"},{"line_number":114,"context_line":"of ``get_instance_host_status``) when policy ``show:host_status`` is allowed"},{"line_number":115,"context_line":"for the given request context (the policy defaults to admin-only)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Other deployer impact"},{"line_number":118,"context_line":"---------------------"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_45dd386e","line":116,"in_reply_to":"9fb8cfa7_c16fdd25","updated":"2019-06-26 21:27:31.000000000","message":"Well, this proposal covers those cases too, right? I used ACTIVE as the primary example but the proposal is to show UNKNOWN if service_is_up is False, for server list and server show.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ef1c3437a295a91ef547d159cd9b2ac0af43b9e","unresolved":false,"context_lines":[{"line_number":169,"context_line":"No additional documentation appears to be needed. The existing `server status`_"},{"line_number":170,"context_line":"documentation explains the UNKNOWN status value."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":".. _server status: https://developer.openstack.org/api-guide/compute/server_concepts.html#server-status"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"References"},{"line_number":175,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_0153b56c","line":172,"updated":"2019-06-26 20:45:36.000000000","message":"This is not the same as what you\u0027re proposing. Unless I\u0027m mistaken, you\u0027re proposing to just mask the returned status as UNKNOWN and leave everything else the same assuming we can reach the cell database to get the instance related information. The UNKNOWN status we have now returns a partial result of the server response body because we literally can\u0027t build the full response because we can\u0027t get the details from the cell database.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cdf69db667af1d57a2e0832afd269a51c764d611","unresolved":false,"context_lines":[{"line_number":169,"context_line":"No additional documentation appears to be needed. The existing `server status`_"},{"line_number":170,"context_line":"documentation explains the UNKNOWN status value."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":".. _server status: https://developer.openstack.org/api-guide/compute/server_concepts.html#server-status"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"References"},{"line_number":175,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_254e0438","line":172,"in_reply_to":"9fb8cfa7_0153b56c","updated":"2019-06-26 21:27:31.000000000","message":"I considered it to be the same because it\u0027s intentionally generic. It says, \"UNKNOWN: The state of the server is unknown. It could be because a part of the infrastructure is temporarily down (see Handling Down Cells for more information). Contact your cloud provider.\"\n\nTo me, that\u0027s reads that UNKNOWN means it\u0027s possible a cell is down but it\u0027s written to encompass any unknown status and not a contract that UNKNOWN must mean a cell is down.","commit_id":"364bf6eea9852822ed12d5938054e3c3d2a718ef"}]}