)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"7b2a10acb80a271e95480700bdeddd0d9bdc6365","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This spec aims at providing more flexibility for operators regarding the"},{"line_number":10,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":11,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":12,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":13,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":14,"context_line":"the physical instance to be the source of truth and make nova update its"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9fdfeff1_2afda139","line":11,"range":{"start_line":11,"start_character":72,"end_line":11,"end_character":78},"updated":"2019-02-11 16:23:53.000000000","message":"Let\u0027s wrap these long lines?","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"d19102b9c963c254b270ebb1358d5244f0332e9b","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This spec aims at providing more flexibility for operators regarding the"},{"line_number":10,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":11,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":12,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":13,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":14,"context_line":"the physical instance to be the source of truth and make nova update its"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"5fc1f717_df75ebfb","line":11,"range":{"start_line":11,"start_character":72,"end_line":11,"end_character":78},"in_reply_to":"9fdfeff1_2afda139","updated":"2019-03-21 15:32:01.000000000","message":"Done","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"be5438d4934663733c4b6c751925f124f38a6e18","unresolved":false,"context_lines":[{"line_number":14,"context_line":"situations, like to allow the physical instance to be the source of"},{"line_number":15,"context_line":"truth and make nova update its database rather than enforcing the"},{"line_number":16,"context_line":"database state onto the physical instance."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Implements blueprint nova-support-instance-power-update"},{"line_number":19,"context_line":"Change-Id: I91eaf14053ecac38dd116ec67feb1f5bafa64226"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"ffb9cba7_d005ed7b","line":17,"updated":"2019-04-23 09:02:37.000000000","message":"add the story and task number for the ironic side in the next iteration.","commit_id":"13128f78197caaec92a8aade96094f569906cfe4"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"505a968bdcc9bd601e483f9f353c271176fa6611","unresolved":false,"context_lines":[{"line_number":14,"context_line":"situations, like to allow the physical instance to be the source of"},{"line_number":15,"context_line":"truth and make nova update its database rather than enforcing the"},{"line_number":16,"context_line":"database state onto the physical instance."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Implements blueprint nova-support-instance-power-update"},{"line_number":19,"context_line":"Change-Id: I91eaf14053ecac38dd116ec67feb1f5bafa64226"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"dfbec78f_6bbbc271","line":17,"in_reply_to":"ffb9cba7_d005ed7b","updated":"2019-05-08 18:40:24.000000000","message":"Done","commit_id":"13128f78197caaec92a8aade96094f569906cfe4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"095b19adcf6b89ab9c2b68c38c039d85180bb68b","unresolved":false,"context_lines":[{"line_number":10,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":11,"context_line":"between the database and the hypervisor) in nova with respect to use"},{"line_number":12,"context_line":"cases for the baremetal instances (ironic). It proposes to make this"},{"line_number":13,"context_line":"periodic power sync\u0027s \"source of truth\" configurable, depending on"},{"line_number":14,"context_line":"situations, like to allow the physical instance to be the source of"},{"line_number":15,"context_line":"truth and make nova update its database rather than enforcing the"},{"line_number":16,"context_line":"database state onto the physical instance."},{"line_number":17,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":7,"id":"bfb3d3c7_e1a4c1bb","line":14,"range":{"start_line":13,"start_character":40,"end_line":14,"end_character":10},"updated":"2019-05-22 02:27:43.000000000","message":"Note to reviewers: this is residue and not part of the proposal anymore.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"}],"specs/train/approved/nova-support-instance-power-update.rst":[{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"291f642256fdde79bb8b8f05d979f14118a4ae32","unresolved":false,"context_lines":[{"line_number":14,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":15,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":16,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":17,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":18,"context_line":"the physical instance to be the source of truth and make nova update its"},{"line_number":19,"context_line":"database rather than enforcing the database state onto the physical instance."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_eb7f8c63","line":17,"range":{"start_line":17,"start_character":25,"end_line":17,"end_character":37},"updated":"2019-02-12 09:41:14.000000000","message":"@jroll: probably wrong wording, I actually did not mean to make it configurable for this particular situation unless operators want that, by configurable I mean for the physical instance related unpredictable situations (or at least that is our use case) since it doesn\u0027t matter for the virtual instances as they cannot be brought up without nova knowing.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"53c15727622ec39067195a02cc56af72392f2ee2","unresolved":false,"context_lines":[{"line_number":14,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":15,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":16,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":17,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":18,"context_line":"the physical instance to be the source of truth and make nova update its"},{"line_number":19,"context_line":"database rather than enforcing the database state onto the physical instance."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_483635b7","line":17,"range":{"start_line":17,"start_character":25,"end_line":17,"end_character":37},"in_reply_to":"5fc1f717_e22062b3","updated":"2019-03-20 19:39:22.000000000","message":"Also thinking more about this we would not need to do it when \"force_power_state_during_sync\" is True since that info is already with nova during its periodic power syncing from the ironic db.\n\nSo I guess we would need ironic to send an event only when:\n\na) ironic api call to power on the node.\nb) when force_power_state_during_sync is False and the hw/db don\u0027t agree which would basically be situations leading to db update from the hardware.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"46d8e17597795429b6ae05f241b80f545d12ff5d","unresolved":false,"context_lines":[{"line_number":14,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":15,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":16,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":17,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":18,"context_line":"the physical instance to be the source of truth and make nova update its"},{"line_number":19,"context_line":"database rather than enforcing the database state onto the physical instance."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_e22062b3","line":17,"range":{"start_line":17,"start_character":25,"end_line":17,"end_character":37},"in_reply_to":"9fdfeff1_2d7fe4e0","updated":"2019-03-20 18:37:09.000000000","message":"discussed with jroll:\n\n tssurya │ jroll: so regarding ironic having the knowledge regarding at which instance is the machine source of truth versus db.. how does ironic know that ?                                                                                                                                \n jroll   │ tssurya: we have the \"force_power_state_during_sync\" config option in ironic-conductor - \"During sync_power_state, should the hardware     power state be set to the state recorded in the database (True) or should the database be updated based on the hardware state (False).\" \n tssurya │ however this is for all the nodes right ? either we regard the db as truth or hardware ? \n tssurya │ ok I think now I get what you meant: something like we should just send the events to nova when we find that the hardware and db state don\u0027t match if force_power_state_during_sync is False and not for every ironic polling right ?                                               \n tssurya │ I can leave a comment on the review regarding this\n jroll   │ yes, for all the nodes. and yes, do it based on that config option being False - if we update our database to match, we should also update\n tssurya │ jroll: makes sense!","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"7ea921813484ee8464ee24e3474e0feedceb68dd","unresolved":false,"context_lines":[{"line_number":14,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":15,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":16,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":17,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":18,"context_line":"the physical instance to be the source of truth and make nova update its"},{"line_number":19,"context_line":"database rather than enforcing the database state onto the physical instance."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_2d7fe4e0","line":17,"range":{"start_line":17,"start_character":25,"end_line":17,"end_character":37},"in_reply_to":"9fdfeff1_eb7f8c63","updated":"2019-02-12 14:43:47.000000000","message":"Right. I meant for all ironic instances, for any power state change, accept what Ironic says as the source of truth. Combined with sending every power state change from Ironic to Nova, then Nova should always be up to date.\n\nThinking more... Ironic\u0027s behavior for unexpected power changes is configurable. Maybe we only make Ironic send the notification to Nova if Ironic takes the machine (not the DB) as the source of truth?","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"df91778c0e2e80285cae01067f2bcc38785d49ce","unresolved":false,"context_lines":[{"line_number":28,"context_line":"hypervisor is regarded as the source of truth. However when the physical"},{"line_number":29,"context_line":"instance comes up again through non-api methods like the IPMI access or the"},{"line_number":30,"context_line":"power button, it will be put into the ``SHUTDOWN`` state again by nova"},{"line_number":31,"context_line":"since the database (indirectly the hypervisor) is regarded as the source of"},{"line_number":32,"context_line":"truth here. This can cause operational inconvenience and inconsistency between"},{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"},{"line_number":34,"context_line":"completely disabling the power synchronisation which is not recommended."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_47b6688c","line":31,"range":{"start_line":31,"start_character":19,"end_line":31,"end_character":46},"updated":"2019-03-18 14:22:21.000000000","message":"well, looks like its not exactly the hypervisor which is the source of truth though it should be which is the problem. When we get the life_cycle_event for the node coming back up we change the power_state back to \"running\" in the db which is correct since the hypervisor is the source of truth however since the vm_state is still \"STOPPED\" we somehow regard the DB to be the source or truth and go against the hypervisor shouting \"RUNNING\" and we put the node back into SHUTDOWN power_state, (https://github.com/openstack/nova/blob/926e584136e7dce59f32065292aa4eb8120f628c/nova/compute/manager.py#L7873)","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"53c15727622ec39067195a02cc56af72392f2ee2","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Proposed change"},{"line_number":49,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"To make nova hear the physical instance come up and regard it as the source of"},{"line_number":52,"context_line":"truth, the idea is to add a ``power-update`` event name to the"},{"line_number":53,"context_line":"``os-server-external-events`` nova API. This event will be `sent by ironic`_"},{"line_number":54,"context_line":"whenever there is a change in the power state of the down physical instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_6888d170","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":17},"updated":"2019-03-20 19:39:22.000000000","message":"we should also add a config option for backwards compatibility in case people don\u0027t want nova to do anything even if it receives the event from the new microversion.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"7b2a10acb80a271e95480700bdeddd0d9bdc6365","unresolved":false,"context_lines":[{"line_number":52,"context_line":"truth, the idea is to add a ``power-update`` event name to the"},{"line_number":53,"context_line":"``os-server-external-events`` nova API. This event will be `sent by ironic`_"},{"line_number":54,"context_line":"whenever there is a change in the power state of the down physical instance"},{"line_number":55,"context_line":"i.e. when the physical instance comes up via a non-api call. Nova will be"},{"line_number":56,"context_line":"listening for the ``power-update`` event from ironic using the existing"},{"line_number":57,"context_line":"external-events API endpoint as discussed in the `nova-ironic cross project"},{"line_number":58,"context_line":"session at the Denver2018 PTG`_."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_7eca8a6e","line":55,"range":{"start_line":55,"start_character":5,"end_line":55,"end_character":59},"updated":"2019-02-11 16:23:53.000000000","message":"Would it make sense for ironic to always emit power state events and nova always listens to them?\n\nI am thinking that having ironic polling nodes is a necessary evil (because nodes generally can\u0027t send power up/down notifications) leading to sloppily synchronized power states.\n\nBut may be we could do it better between ironic and nova meaning instant power state change notification going out of ironic towards nova?","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"7ea921813484ee8464ee24e3474e0feedceb68dd","unresolved":false,"context_lines":[{"line_number":52,"context_line":"truth, the idea is to add a ``power-update`` event name to the"},{"line_number":53,"context_line":"``os-server-external-events`` nova API. This event will be `sent by ironic`_"},{"line_number":54,"context_line":"whenever there is a change in the power state of the down physical instance"},{"line_number":55,"context_line":"i.e. when the physical instance comes up via a non-api call. Nova will be"},{"line_number":56,"context_line":"listening for the ``power-update`` event from ironic using the existing"},{"line_number":57,"context_line":"external-events API endpoint as discussed in the `nova-ironic cross project"},{"line_number":58,"context_line":"session at the Denver2018 PTG`_."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_4d4588b3","line":55,"range":{"start_line":55,"start_character":5,"end_line":55,"end_character":59},"in_reply_to":"9fdfeff1_4b3258f4","updated":"2019-02-12 14:43:47.000000000","message":"\u003e Hmm, notifications for every power state change? Let\u0027s see what the\n \u003e nova team thinks..\n\nI\u0027m fairly certain this is what was proposed in the last PTG. I still think it makes sense.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"d19102b9c963c254b270ebb1358d5244f0332e9b","unresolved":false,"context_lines":[{"line_number":52,"context_line":"truth, the idea is to add a ``power-update`` event name to the"},{"line_number":53,"context_line":"``os-server-external-events`` nova API. This event will be `sent by ironic`_"},{"line_number":54,"context_line":"whenever there is a change in the power state of the down physical instance"},{"line_number":55,"context_line":"i.e. when the physical instance comes up via a non-api call. Nova will be"},{"line_number":56,"context_line":"listening for the ``power-update`` event from ironic using the existing"},{"line_number":57,"context_line":"external-events API endpoint as discussed in the `nova-ironic cross project"},{"line_number":58,"context_line":"session at the Denver2018 PTG`_."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_5f9edb07","line":55,"range":{"start_line":55,"start_character":5,"end_line":55,"end_character":59},"in_reply_to":"9fdfeff1_7eca8a6e","updated":"2019-03-21 15:32:01.000000000","message":"\u003e Would it make sense for ironic to always emit power state events\n \u003e and nova always listens to them?\n\nSo we were thinking of sending update-events when\n\n1) force_power_state_during_sync is false, i.e when ironic regards hw as source of truth and it sees a node has come up.\n\n2) when we do baremetal node set power on api call.\n\n\nWe would not have to handle force_power_state_during_sync being true since that is already handled by today\u0027s power sync between nova and ironic based on the db status.\n\n \u003e \n \u003e I am thinking that having ironic polling nodes is a necessary evil\n \u003e (because nodes generally can\u0027t send power up/down notifications)\n \u003e leading to sloppily synchronized power states.\n \u003e \n \u003e But may be we could do it better between ironic and nova meaning\n \u003e instant power state change notification going out of ironic towards\n \u003e nova?\n\nand of course I agree that ironic polling can lead to sloppy syncing depending on the interval time of polling, not sure if we should do a new design on the ironic side if I understand correctly.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"291f642256fdde79bb8b8f05d979f14118a4ae32","unresolved":false,"context_lines":[{"line_number":52,"context_line":"truth, the idea is to add a ``power-update`` event name to the"},{"line_number":53,"context_line":"``os-server-external-events`` nova API. This event will be `sent by ironic`_"},{"line_number":54,"context_line":"whenever there is a change in the power state of the down physical instance"},{"line_number":55,"context_line":"i.e. when the physical instance comes up via a non-api call. Nova will be"},{"line_number":56,"context_line":"listening for the ``power-update`` event from ironic using the existing"},{"line_number":57,"context_line":"external-events API endpoint as discussed in the `nova-ironic cross project"},{"line_number":58,"context_line":"session at the Denver2018 PTG`_."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_4b3258f4","line":55,"range":{"start_line":55,"start_character":5,"end_line":55,"end_character":59},"in_reply_to":"9fdfeff1_7eca8a6e","updated":"2019-02-12 09:41:14.000000000","message":"\u003e Would it make sense for ironic to always emit power state events\n \u003e and nova always listens to them?\n \u003e \n\nI was just focussing on our use case, but sure, we could have this, just depends on what \"power state events\" , mean here, in the sense that I don\u0027t know how one \"power_update\" event could determine if the server has to be put to ACTIVE or SHUTDOWN.\n\n \u003e I am thinking that having ironic polling nodes is a necessary evil\n \u003e (because nodes generally can\u0027t send power up/down notifications)\n \u003e leading to sloppily synchronized power states.\n \u003e \n \u003e But may be we could do it better between ironic and nova meaning\n \u003e instant power state change notification going out of ironic towards\n \u003e nova?\n\nHmm, notifications for every power state change? Let\u0027s see what the nova team thinks..","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"273efc74ffec2c2d8daff023eb4b51321dc4f6d1","unresolved":false,"context_lines":[{"line_number":60,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":61,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":62,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. Doing this by"},{"line_number":63,"context_line":"using the compute_api.start() call would make this cleaner."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_e80e0131","line":63,"range":{"start_line":63,"start_character":0,"end_line":63,"end_character":58},"updated":"2019-03-20 19:30:05.000000000","message":"nope, this would put it to a loop, where we just got a \"on\" request from ironic and then we send back the on request to ironic. : https://github.com/openstack/nova/blob/59f1f187e5dceb5841a711f265280346d70a972b/nova/virt/ironic/driver.py#L1450 \n\nmight make this more chatty and redundant since the node is already on, probably the best is to set the vm_state to ACTIVE and power_state to RUNNING. Hopefully it doesn\u0027t matter if the task_state doesn\u0027t go through the \"POWERING_ON\" task_state since the node is already ON.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"52b9e327c38614e4f4a7b94d446dcd49126a6843","unresolved":false,"context_lines":[{"line_number":60,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":61,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":62,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. Doing this by"},{"line_number":63,"context_line":"using the compute_api.start() call would make this cleaner."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_4d1b9a72","line":63,"range":{"start_line":63,"start_character":0,"end_line":63,"end_character":58},"in_reply_to":"5fc1f717_32c0ef50","updated":"2019-03-21 10:38:54.000000000","message":"option #3 would be to just set the vm_state to active and then let the power sync do what it wants in the next cycle (although the fear here is \"if\" we will be missing any essential steps in the start instance path.)","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"88a2f2dfd1fb0a51b59455581dad97b7240085a7","unresolved":false,"context_lines":[{"line_number":60,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":61,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":62,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. Doing this by"},{"line_number":63,"context_line":"using the compute_api.start() call would make this cleaner."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_32c0ef50","line":63,"range":{"start_line":63,"start_character":0,"end_line":63,"end_character":58},"in_reply_to":"5fc1f717_e80e0131","updated":"2019-03-21 10:20:49.000000000","message":"\u003e nope, this would put it to a loop, where we just got a \"on\" request\n \u003e from ironic and then we send back the on request to ironic. :\n \u003e https://github.com/openstack/nova/blob/59f1f187e5dceb5841a711f265280346d70a972b/nova/virt/ironic/driver.py#L1450\n \u003e \n \u003e might make this more chatty and redundant since the node is already\n \u003e on, probably the best is to set the vm_state to ACTIVE and\n \u003e power_state to RUNNING. Hopefully it doesn\u0027t matter if the\n \u003e task_state doesn\u0027t go through the \"POWERING_ON\" task_state since\n \u003e the node is already ON.\n\nrethinking this, it has to go through the start API for the normal sort of start-up steps like action starts/end notifications etc., but we need to figure out a way to not go into the driver.power_on() call since its the driver (ironic) that instructed us to do this in the first place. I have two options:\n\n1) modify the compute_api.start() declaration which will need RPC bump to add the \"call_driver\u003dTrue\" parameter.\n2) just let this loop back to ironic which hopefully silently ignores the power_on() call since its already on.","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"291f642256fdde79bb8b8f05d979f14118a4ae32","unresolved":false,"context_lines":[{"line_number":185,"context_line":""},{"line_number":186,"context_line":"#. Add the new external-event type."},{"line_number":187,"context_line":"#. Make the necessary changes in the compute API for the update of the power"},{"line_number":188,"context_line":"   and task states of the instance."},{"line_number":189,"context_line":"#. Add the new microversion."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_081bf680","line":188,"range":{"start_line":188,"start_character":7,"end_line":188,"end_character":11},"updated":"2019-02-12 09:41:14.000000000","message":"vm","commit_id":"6f07431b50f748d097672a7a4b721ec1e2834f20"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fa8d4ced06b6ff3edc2da145c150474c020575dd","unresolved":false,"context_lines":[{"line_number":59,"context_line":"session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":63,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. This will be done"},{"line_number":64,"context_line":"using the compute_api.start() call so that the instance start action and"},{"line_number":65,"context_line":"notifications all happen as per regular instance start API call logic."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_298f0124","line":63,"range":{"start_line":62,"start_character":8,"end_line":63,"end_character":58},"updated":"2019-03-22 15:10:48.000000000","message":"Surely you mean that nova will poll ironic for the current state and update itself, right? The event is \"power update\" not \"powered on\" and I would expect similar behaviors to be desirable for when the instance goes from ACTIVE to SHUTOFF because someone powered it off manually, right?","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"7786a56eeec2ef7b319dcfb26f7078c52ddce766","unresolved":false,"context_lines":[{"line_number":59,"context_line":"session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":63,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. This will be done"},{"line_number":64,"context_line":"using the compute_api.start() call so that the instance start action and"},{"line_number":65,"context_line":"notifications all happen as per regular instance start API call logic."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_0f44851a","line":63,"range":{"start_line":62,"start_character":8,"end_line":63,"end_character":58},"in_reply_to":"5fc1f717_0986c5dc","updated":"2019-03-22 16:13:54.000000000","message":"yea its what melwitt said, ironic sends event and nova responds by powering on the node i.e compute_api.start() instance.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"7786a56eeec2ef7b319dcfb26f7078c52ddce766","unresolved":false,"context_lines":[{"line_number":59,"context_line":"session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":63,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. This will be done"},{"line_number":64,"context_line":"using the compute_api.start() call so that the instance start action and"},{"line_number":65,"context_line":"notifications all happen as per regular instance start API call logic."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_0fe005fa","line":63,"range":{"start_line":62,"start_character":8,"end_line":63,"end_character":58},"in_reply_to":"5fc1f717_298f0124","updated":"2019-03-22 16:13:54.000000000","message":"\u003e Surely you mean that nova will poll ironic for the current state\n \u003e and update itself, right? \n\nnova will get the event from ironic and do the needful for setting the vm_state to ACTIVE so that in the next iteration of power_sync it doesn\u0027t shut this node down.\n\n \u003e The event is \"power update\" not \"powered\n \u003e on\" and I would expect similar behaviors to be desirable for when\n \u003e the instance goes from ACTIVE to SHUTOFF because someone powered it\n \u003e off manually, right?\n\nmaybe the name \"power-update\" is misleading I could call it \"power-on\" because what we do today with the power sync already covers the later when someone shuts off the node/instance nova shuts it down, its just that nova doesn\u0027t like to bring them back up. Its an asynchronous option. \n\nThese events are only for powering on action; powering off is something nova loves to do already and does it during power sync and doing this here also would be redundant unless we stop periodic power syncing with ironic ?","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8fdaeeda22b736267f192dbfb2d9de32060b9b36","unresolved":false,"context_lines":[{"line_number":59,"context_line":"session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":63,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` in the nova database. This will be done"},{"line_number":64,"context_line":"using the compute_api.start() call so that the instance start action and"},{"line_number":65,"context_line":"notifications all happen as per regular instance start API call logic."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_0986c5dc","line":63,"range":{"start_line":62,"start_character":8,"end_line":63,"end_character":58},"in_reply_to":"5fc1f717_298f0124","updated":"2019-03-22 15:15:13.000000000","message":"Hm, when we discussed this at the PTG [1], we had agreed that ironic would sent us an external event and we\u0027d update instance state accordingly.\n\n[1] L661 https://etherpad.openstack.org/p/nova-ptg-stein","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fa8d4ced06b6ff3edc2da145c150474c020575dd","unresolved":false,"context_lines":[{"line_number":78,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"},{"line_number":79,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":80,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":81,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Alternatives"},{"line_number":84,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_691bc91a","line":81,"updated":"2019-03-22 15:10:48.000000000","message":"What is the reasoning for allowing it to be set back to broken mode? If nothing sends any events, then we\u0027re effectively behaving like we used to, and if ironic sends events, then clearly they\u0027re running a new ironic and we should just do the right thing, I would think.\n\nWhy make operators opt-in to correct behavior, and/or what circumstances would actually dictate leaving this disabled?","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"7786a56eeec2ef7b319dcfb26f7078c52ddce766","unresolved":false,"context_lines":[{"line_number":78,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"},{"line_number":79,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":80,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":81,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Alternatives"},{"line_number":84,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_c9fe7d37","line":81,"in_reply_to":"5fc1f717_691bc91a","updated":"2019-03-22 16:13:54.000000000","message":"I had not added this config initially when defining the spec and frankly I don\u0027t know under what circumstances an operator might not want ironic hardware to be the source of truth, but I added this option only as a fail safe, in case someone is paranoid enough to want the db as the source of truth. I can remove this option if all are on board if allowing ironic to update the instance state.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fa8d4ced06b6ff3edc2da145c150474c020575dd","unresolved":false,"context_lines":[{"line_number":102,"context_line":"        \"events\": ["},{"line_number":103,"context_line":"            {"},{"line_number":104,"context_line":"                \"name\": \"power-update\","},{"line_number":105,"context_line":"                \"server_uuid\": \"3df201cf-2451-44f2-8d25-a4ca826fc1f3\""},{"line_number":106,"context_line":"            }"},{"line_number":107,"context_line":"        ]"},{"line_number":108,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_09aec597","line":105,"updated":"2019-03-22 15:10:48.000000000","message":"Is there any reason to communicate the new state in this event? There is a tag field which is basically free-form context data. It is used by neutron to indicate a port id for example, and could be used to indicate the new power state if that\u0027s desirable. Or maybe it\u0027s just best to use this as a kick to tell nova to refresh?","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"9383109cfc8efb2f41606ec77c8aeaf076615e29","unresolved":false,"context_lines":[{"line_number":102,"context_line":"        \"events\": ["},{"line_number":103,"context_line":"            {"},{"line_number":104,"context_line":"                \"name\": \"power-update\","},{"line_number":105,"context_line":"                \"server_uuid\": \"3df201cf-2451-44f2-8d25-a4ca826fc1f3\""},{"line_number":106,"context_line":"            }"},{"line_number":107,"context_line":"        ]"},{"line_number":108,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_b0e4890e","line":105,"in_reply_to":"5fc1f717_09aec597","updated":"2019-03-25 08:44:06.000000000","message":"yea just a kick, unless we want to add both power on and off actions as a part of the \"power-update\" event in which case the tag can be off or on, shouldn\u0027t be needed I guess.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"0496597e48085fbee3f90d4eb66ed89e64017f5d","unresolved":false,"context_lines":[{"line_number":102,"context_line":"        \"events\": ["},{"line_number":103,"context_line":"            {"},{"line_number":104,"context_line":"                \"name\": \"power-update\","},{"line_number":105,"context_line":"                \"server_uuid\": \"3df201cf-2451-44f2-8d25-a4ca826fc1f3\""},{"line_number":106,"context_line":"            }"},{"line_number":107,"context_line":"        ]"},{"line_number":108,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_de1fd605","line":105,"in_reply_to":"5fc1f717_b0e4890e","updated":"2019-03-25 16:08:48.000000000","message":"discussing further with ironic, we plan to send events for both ups and downs.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fa8d4ced06b6ff3edc2da145c150474c020575dd","unresolved":false,"context_lines":[{"line_number":210,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"* The Ironic changes needed to send the event when the physical instance comes"},{"line_number":213,"context_line":"  up."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"Testing"},{"line_number":216,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_49bb6dc3","line":213,"updated":"2019-03-22 15:10:48.000000000","message":"Is there an ironic spec or patch for this? If so, reference it here.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"7786a56eeec2ef7b319dcfb26f7078c52ddce766","unresolved":false,"context_lines":[{"line_number":210,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"* The Ironic changes needed to send the event when the physical instance comes"},{"line_number":213,"context_line":"  up."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"Testing"},{"line_number":216,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5fc1f717_6fac298c","line":213,"in_reply_to":"5fc1f717_49bb6dc3","updated":"2019-03-22 16:13:54.000000000","message":"I had asked ironic, they said a RFE is fine so we have one here: https://storyboard.openstack.org/#!/story/2004969 which I linked above but will link it here too. I will be doing the ironic changes too its just that the ironic team wanted to see some progress on the nova side so started with nova side changes.","commit_id":"a63d5bc5bb1cde6cb24405324ec51e7371e2f8cb"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"d95f6b19eaec77f503536635a81480e52b3aa8f2","unresolved":false,"context_lines":[{"line_number":219,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* The Ironic changes needed to send the event when the physical instance comes"},{"line_number":222,"context_line":"  up."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Testing"},{"line_number":225,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5fc1f717_d948502e","line":222,"updated":"2019-03-25 16:31:25.000000000","message":"dammit: forgot to link","commit_id":"8716e99069e71e6075031f4f52019e5204714e5a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":24,"context_line":"As a part of this periodic power sync between nova and ironic, when a physical"},{"line_number":25,"context_line":"instance goes down during situations like a power outage or when the hardware"},{"line_number":26,"context_line":"team with direct physical access to the machine does system repairs, the"},{"line_number":27,"context_line":"instance is put into the ``SHUTDOWN`` state by nova in its database since the"},{"line_number":28,"context_line":"hypervisor is regarded as the source of truth. However when the physical"},{"line_number":29,"context_line":"instance comes up again through non-nova-api methods like the IPMI access or"},{"line_number":30,"context_line":"the power button, it will be put into the ``SHUTDOWN`` state again by nova"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_6c1dbc60","line":27,"updated":"2019-04-09 14:10:54.000000000","message":"So here you\u0027re talking about this case specifically:\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L7871","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":24,"context_line":"As a part of this periodic power sync between nova and ironic, when a physical"},{"line_number":25,"context_line":"instance goes down during situations like a power outage or when the hardware"},{"line_number":26,"context_line":"team with direct physical access to the machine does system repairs, the"},{"line_number":27,"context_line":"instance is put into the ``SHUTDOWN`` state by nova in its database since the"},{"line_number":28,"context_line":"hypervisor is regarded as the source of truth. However when the physical"},{"line_number":29,"context_line":"instance comes up again through non-nova-api methods like the IPMI access or"},{"line_number":30,"context_line":"the power button, it will be put into the ``SHUTDOWN`` state again by nova"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_09abc187","line":27,"in_reply_to":"5fc1f717_6c1dbc60","updated":"2019-04-10 17:30:06.000000000","message":"Done","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":27,"context_line":"instance is put into the ``SHUTDOWN`` state by nova in its database since the"},{"line_number":28,"context_line":"hypervisor is regarded as the source of truth. However when the physical"},{"line_number":29,"context_line":"instance comes up again through non-nova-api methods like the IPMI access or"},{"line_number":30,"context_line":"the power button, it will be put into the ``SHUTDOWN`` state again by nova"},{"line_number":31,"context_line":"since the database is regarded as the source of truth here (asynchronous)."},{"line_number":32,"context_line":"This can cause operational inconvenience and inconsistency between"},{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_6c529c14","line":30,"updated":"2019-04-09 14:10:54.000000000","message":"And here you\u0027re talking about this case:\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L7915","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":27,"context_line":"instance is put into the ``SHUTDOWN`` state by nova in its database since the"},{"line_number":28,"context_line":"hypervisor is regarded as the source of truth. However when the physical"},{"line_number":29,"context_line":"instance comes up again through non-nova-api methods like the IPMI access or"},{"line_number":30,"context_line":"the power button, it will be put into the ``SHUTDOWN`` state again by nova"},{"line_number":31,"context_line":"since the database is regarded as the source of truth here (asynchronous)."},{"line_number":32,"context_line":"This can cause operational inconvenience and inconsistency between"},{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_49c0e950","line":30,"in_reply_to":"5fc1f717_6c529c14","updated":"2019-04-10 17:30:06.000000000","message":"Done","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":30,"context_line":"the power button, it will be put into the ``SHUTDOWN`` state again by nova"},{"line_number":31,"context_line":"since the database is regarded as the source of truth here (asynchronous)."},{"line_number":32,"context_line":"This can cause operational inconvenience and inconsistency between"},{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"},{"line_number":34,"context_line":"completely disabling the power synchronisation which is not recommended."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Note that ironic allows a node to be put into the ``maintenance mode`` by which"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0c43d840","line":33,"range":{"start_line":33,"start_character":48,"end_line":33,"end_character":70},"updated":"2019-04-09 14:10:54.000000000","message":"Is this really the *only* way? Can\u0027t the user working on the baremetal instance out-of-band from nova be using the compute API to stop and start the instance during maintenance to avoid the periodic task having to guess?\n\nReading ahead, I guess that would work for scheduled maintenance but not something unexpected like a power failure (L39).","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"},{"line_number":34,"context_line":"completely disabling the power synchronisation which is not recommended."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Note that ironic allows a node to be put into the ``maintenance mode`` by which"},{"line_number":37,"context_line":"that node will be excluded from nova\u0027s ``_sync_power_states`` periodic task."},{"line_number":38,"context_line":"This covers predictable events like scheduled repairs but does not help with"},{"line_number":39,"context_line":"unforseen events such as power failures."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0c8af862","line":36,"updated":"2019-04-09 14:10:54.000000000","message":"Is that what gets handled here?\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L7696\n\nOr related to Jim\u0027s change I907b69eb689cf6c169a4869cfc7889308ca419d5?\n\nOr something specific in the ironic driver?\n\nOr something else? Links/references would be helpful in the spec.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":33,"context_line":"cloud operators and repair teams. Currently the only way to avoid this is by"},{"line_number":34,"context_line":"completely disabling the power synchronisation which is not recommended."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Note that ironic allows a node to be put into the ``maintenance mode`` by which"},{"line_number":37,"context_line":"that node will be excluded from nova\u0027s ``_sync_power_states`` periodic task."},{"line_number":38,"context_line":"This covers predictable events like scheduled repairs but does not help with"},{"line_number":39,"context_line":"unforseen events such as power failures."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_112c3197","line":36,"in_reply_to":"5fc1f717_0c8af862","updated":"2019-04-10 17:30:06.000000000","message":"Done","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, the ``vm_state`` and ``power_state`` fields of that instance will be"},{"line_number":63,"context_line":"updated to ``ACTIVE`` and ``RUNNING`` (or ``STOPPED`` and ``SHUTDOWN``) in"},{"line_number":64,"context_line":"the nova database. This will be done using the compute_api.start() (or"},{"line_number":65,"context_line":"compute_api.stop()) call so that the instance start (or stop) action and"},{"line_number":66,"context_line":"notifications all happen as per regular instance start (or stop) API call"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_ac896426","line":63,"updated":"2019-04-09 14:10:54.000000000","message":"How will nova determine the state the instance should be in? Is that going to be in the event payload which today is pretty limited: you get an event name (power-update), server_uuid, status (which is an enum) and tag, which for existing events the tag is a port id or a volume id. Would we make the status or tag fields as the node status? Or would the API call down to the compute service (and driver) to get the node power state information?\n\n(later)\n\nOK I see later that \u0027tag\u0027 will be used.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fbfcb3ea2a5c5df238ba341dd21157728bb0aa7c","unresolved":false,"context_lines":[{"line_number":64,"context_line":"the nova database. This will be done using the compute_api.start() (or"},{"line_number":65,"context_line":"compute_api.stop()) call so that the instance start (or stop) action and"},{"line_number":66,"context_line":"notifications all happen as per regular instance start (or stop) API call"},{"line_number":67,"context_line":"logic."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The compute_api.start() and compute_api.stop() methods indirectly call the"},{"line_number":70,"context_line":"driver to power on/off the node. So in order to use the compute_api.start()"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_bb19a088","line":67,"updated":"2019-04-09 12:22:40.000000000","message":"+1","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_4ccc8088","line":74,"updated":"2019-04-09 14:10:54.000000000","message":"Alternatively the compute API could just not call the compute service (manager) code and flip the DB values in the API, right? Although there is other logic in the compute manager stop_instance and start_instance methods plus other sugar like notifications and recording the instance action event - we wouldn\u0027t want to duplicate that in the API.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"3bb54231805249a0f36a2354ccf2a2a5fb1d3425","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ffb9cba7_adeee285","line":74,"in_reply_to":"3fce034c_1fc12c2f","updated":"2019-04-23 08:32:17.000000000","message":"@dansmith: thanks for clarifying this, so it would be something similar to what I have here: https://review.opendev.org/#/c/645611/1/nova/compute/manager.py except we call the driver directly and handle notifications and instance actions separately.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bf96aeee1dfb9e2aa8aa300fbee06ed4ae21e8c1","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fce034c_1fc12c2f","line":74,"in_reply_to":"3fce034c_69832258","updated":"2019-04-15 17:41:38.000000000","message":"Don\u0027t look at network-vif-plugged, because that is handled in a specific synchronous way where the virt driver knows it\u0027s coming. What we want is to handle asynchronous events, more like network-changed. This is the compute handler for events:\n\nhttps://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8344\n\nSo we would add another case there, and call self.driver.power_event(...) or something when that event arrives.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"f174001fa6ba97e7da5a543f36c84ba435e4594d","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fce034c_69832258","line":74,"in_reply_to":"3fce034c_6c033b0f","updated":"2019-04-11 08:29:46.000000000","message":"\u003e Sorry for the half-baked comment. I was thinking about things like\n \u003e this:\n \u003e \n \u003e https://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/virt/libvirt/driver.py#L5660\n \u003e \n \u003e https://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L292\n \u003e \n \u003e https://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L427\n \u003e \n \u003e I don\u0027t yet know exactly how it would be done (direct in driver vs\n \u003e not) but these are the code snippets I know of that handle external\n \u003e events. I don\u0027t remember how the neutron network-vif-plugged events\n \u003e get into the network_info (which is how they\u0027re accessed in the\n \u003e libvirt driver).\n\n\nyea I saw those parts of code and the network-vif-plugged event does go down the \"proper routed way\" from https://github.com/openstack/nova/blob/3a6d48697feee02380d60beeaa81ef619f9c94e3/nova/compute/manager.py#L8228 . Not sure where exactly the listener catches it in the driver.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"2666c41e8a56ac1dbd4dd69b2fe7699b7f532668","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_fc69398b","line":74,"in_reply_to":"5fc1f717_392593c2","updated":"2019-04-10 18:53:01.000000000","message":"\u003e I think what Dan is suggesting is to have the ironic driver itself\n \u003e be the listener for the events from ironic. And have the ironic\n \u003e driver update the instance state itself. That way, there\u0027s no\n \u003e \"calling down to the ironic driver\", the driver itself handles all\n \u003e of it directly.\n \u003e \n \u003e I do like this idea too because it contains the behavior to only\n \u003e the ironic driver, which is the only thing that should ideally be\n \u003e interested in external events from ironic.\n\nI didn\u0027t see you post this :) ended up asking the doubt below. Okay so we don\u0027t \"route\" it. We just dump the event on the ironic driver... err how would the ironic driver directly listen to the os-external-events API? I\u0027ll have to think more about this...","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_89e811df","line":74,"in_reply_to":"5fc1f717_4ccc8088","updated":"2019-04-10 17:30:06.000000000","message":"\u003e Although there is other logic in the compute manager stop_instance\n \u003e and start_instance methods plus other sugar like notifications and\n \u003e recording the instance action event - we wouldn\u0027t want to duplicate\n \u003e that in the API.\n\nyea that\u0027s why I decided to add that flag.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"427717d74ebf609665ae75e4df1384f50021f315","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_58743936","line":74,"in_reply_to":"5fc1f717_4ccc8088","updated":"2019-04-09 16:22:22.000000000","message":"Although if we did flip those states in the DB, the power state sync in the compute node might just do the right thing for us once it notices?\n\nAdding a \"call_driver\u003dFalse\" flag to the start and stop methods seems overly hacky to me and is super specific to this use case (i.e. there\u0027s probably no use for this other than out of band management of ironic nodes). I would hate to see that abused later.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"4aa5ce372194814f5458a7856fdab2dce6ca862e","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_d9ec8f2a","line":74,"in_reply_to":"5fc1f717_5189596c","updated":"2019-04-10 18:01:31.000000000","message":"\u003e \n \u003e hmm, so you prefer duplicating the notifications/event recordings\n \u003e to the API for this specific case ?\n\nah I see below you prefer sending the event all the way to the ironic driver and letting the driver do the change ?","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_5189596c","line":74,"in_reply_to":"5fc1f717_58743936","updated":"2019-04-10 17:30:06.000000000","message":"\u003e Although if we did flip those states in the DB, the power state\n \u003e sync in the compute node might just do the right thing for us once\n \u003e it notices?\n\nit won\u0027t notice anything all since the states would be in sync already which is what we want.\n\n \u003e \n \u003e Adding a \"call_driver\u003dFalse\" flag to the start and stop methods\n \u003e seems overly hacky to me and is super specific to this use case\n \u003e (i.e. there\u0027s probably no use for this other than out of band\n \u003e management of ironic nodes). I would hate to see that abused later.\n\nhmm, so you prefer duplicating the notifications/event recordings to the API for this specific case ?","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e663fe47c83f3bd7dfa5070dfcbfaed1331cf3c4","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_de5b2c51","line":74,"in_reply_to":"5fc1f717_58743936","updated":"2019-04-09 22:10:25.000000000","message":"Yeah, when we talked about this at the PTG I was thinking this would be a DB update without calling through the compute service code. I agree that a call_driver flag sounds overly hacky. If anything, I wonder if we could move the notification and instance action event recording to the API (as opposed to duplicating it) or if there would be some drawback to doing that.\n\nTo Dan\u0027s comment, if we did flip the states in the DB, the power state sync in the compute node would do nothing (no-op), right? Because if we set the state to ACTIVE in the API and the power state that comes back from ironic said RUNNING, then it would do nothing. Same for STOPPED and SHUTDOWN.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cc49ecd622e1045646c9050a5e533951c11a2fec","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_392593c2","line":74,"in_reply_to":"5fc1f717_d9ec8f2a","updated":"2019-04-10 18:34:55.000000000","message":"I think what Dan is suggesting is to have the ironic driver itself be the listener for the events from ironic. And have the ironic driver update the instance state itself. That way, there\u0027s no \"calling down to the ironic driver\", the driver itself handles all of it directly.\n\nI do like this idea too because it contains the behavior to only the ironic driver, which is the only thing that should ideally be interested in external events from ironic.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_f17645a4","line":74,"in_reply_to":"5fc1f717_de5b2c51","updated":"2019-04-10 17:30:06.000000000","message":"\u003e If\n \u003e anything, I wonder if we could move the notification and instance\n \u003e action event recording to the API (as opposed to duplicating it) or\n \u003e if there would be some drawback to doing that.\n\nah if we could move that code to the API that would be perfect. Would it break any existing code path though ? I don\u0027t want to touch the start/stop methods\u0027 current workflow much.\n\n \u003e \n \u003e To Dan\u0027s comment, if we did flip the states in the DB, the power\n \u003e state sync in the compute node would do nothing (no-op), right?\n \u003e Because if we set the state to ACTIVE in the API and the power\n \u003e state that comes back from ironic said RUNNING, then it would do\n \u003e nothing. Same for STOPPED and SHUTDOWN.\n\nyes it would be a no-op which is what we would want.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9fc5255502d0a72bdca409769fc4d64b4af9e44d","unresolved":false,"context_lines":[{"line_number":71,"context_line":"or compute_api.stop() calls in this scenario such that they do not end up in"},{"line_number":72,"context_line":"a loop (ironic sending a power-update event saying the physical instance is up"},{"line_number":73,"context_line":"or down, nova calling the start/stop API only to go back to the ironic driver),"},{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fce034c_6c033b0f","line":74,"in_reply_to":"5fc1f717_fc69398b","updated":"2019-04-10 19:05:56.000000000","message":"Sorry for the half-baked comment. I was thinking about things like this:\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/virt/libvirt/driver.py#L5660\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L292\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/compute/manager.py#L427\n\nI don\u0027t yet know exactly how it would be done (direct in driver vs not) but these are the code snippets I know of that handle external events. I don\u0027t remember how the neutron network-vif-plugged events get into the network_info (which is how they\u0027re accessed in the libvirt driver).","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fbfcb3ea2a5c5df238ba341dd21157728bb0aa7c","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_1b00f401","line":77,"updated":"2019-04-09 12:22:40.000000000","message":"Can we simply route the power-update event to the ironic virt dirver and let that driver update the power state of the instance? Today libvirt driver gets the neutron external events so I think this routing is possible. This way we can avoid passing yet another boolean flag around.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"427717d74ebf609665ae75e4df1384f50021f315","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_f883a501","line":77,"in_reply_to":"5fc1f717_0c1438e8","updated":"2019-04-09 16:22:22.000000000","message":"We could certainly route non-registered events to the virt driver and/or let the virt driver declare which events it cares about (capabilities-style). Personally I think that would be a lot cleaner than compute manager calling its own methods with \"skip driver\" knowing that only happens for one such driver.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0c1438e8","line":77,"in_reply_to":"5fc1f717_1b00f401","updated":"2019-04-09 14:10:54.000000000","message":"But the libvirt (and other) driver is registering a callback for the network-vif-plugged event you\u0027re talking about which is different from this case where nova isn\u0027t actively waiting for something specific (there is no callback registered from the driver in this ironic scenario):\n\nhttps://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/virt/libvirt/driver.py#L5697","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_71f9f5c5","line":77,"in_reply_to":"5fc1f717_217ed169","updated":"2019-04-10 17:30:06.000000000","message":"\u003e but maybe we don\u0027t care.\n\nbut we should right ? This should be reflected in the instance-actions API for that instance.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"6d670494fdc844d6ec8245fdae72be03ac8c8163","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_39a353a0","line":77,"in_reply_to":"5fc1f717_7177b5d5","updated":"2019-04-10 18:10:43.000000000","message":"\u003e \n \u003e I\u0027m actually not sure. Because the notifications and instance\n \u003e action events normally mean (I thought) that a user has initiated\n \u003e something and it\u0027s being notified/recorded. But this is ironic\n \u003e signaling us and causing a change as a result. So it\u0027s not 100%\n \u003e clear to me whether notifications/instance actions are appropriate\n \u003e here.\n\nah I get what you mean,, hmm yeah my thought was just that when nova puts the instance down this would get recorded in the instance actions but when the node comes up via ironic it wouldn\u0027t get recorded which might be weird considering the last action on the instance was a stop but the instance is up.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"daaef92cf5dea94920a647b953168214b7f01855","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_7177b5d5","line":77,"in_reply_to":"5fc1f717_71f9f5c5","updated":"2019-04-10 17:45:14.000000000","message":"\u003e \u003e but maybe we don\u0027t care.\n \u003e \n \u003e but we should right ? This should be reflected in the\n \u003e instance-actions API for that instance.\n\nI\u0027m actually not sure. Because the notifications and instance action events normally mean (I thought) that a user has initiated something and it\u0027s being notified/recorded. But this is ironic signaling us and causing a change as a result. So it\u0027s not 100% clear to me whether notifications/instance actions are appropriate here.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"0038e9bbb4337f5575b369a3430ddae064553680","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_390ef33a","line":77,"in_reply_to":"5fc1f717_f883a501","updated":"2019-04-10 18:36:04.000000000","message":"\u003e We could certainly route non-registered events to the virt driver\n \u003e and/or let the virt driver declare which events it cares about\n \u003e (capabilities-style). Personally I think that would be a lot\n \u003e cleaner than compute manager calling its own methods with \"skip\n \u003e driver\" knowing that only happens for one such driver.\n\nokay so what this means is we route it to the driver like the \"network-vif-plugged\" event, but not making the driver call back to the compute layer whether or not its done? So basically we move the \"direct DB update without any notifications/recording actions\" to the ironic driver layer ?","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e663fe47c83f3bd7dfa5070dfcbfaed1331cf3c4","unresolved":false,"context_lines":[{"line_number":74,"context_line":"we would have to pass a new ``call_driver`` parameter which would be True by"},{"line_number":75,"context_line":"default and False only in the case of the ``power-update`` event in which case"},{"line_number":76,"context_line":"we will not go back to the driver asking it to power on/off the node since the"},{"line_number":77,"context_line":"node is already up/down. This would require a compute RPC version bump."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"In order to preserve backwards compatibility, we will also introduce a config"},{"line_number":80,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_217ed169","line":77,"in_reply_to":"5fc1f717_f883a501","updated":"2019-04-09 22:10:25.000000000","message":"I think this approach would be nice too. Note that we still wouldn\u0027t get notifications or instance action events in this case either AFAIK, but maybe we don\u0027t care.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1a9045223416153f3ebe447c87b279f716b9fb90","unresolved":false,"context_lines":[{"line_number":81,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":82,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":83,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Alternatives"},{"line_number":86,"context_line":"------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_27402f35","line":84,"updated":"2019-04-09 14:22:07.000000000","message":"BTW, you could still race and have the _sync_power_states task stop the instance right? Like if you got the POWER_ON power-update event at t0 before the instance.task_state is set, then at t1 the periodic task runs and stop the instance, and then at t2 the API calls the start_instance method we could hit InstanceInvalidState or UnexpectedTaskStateError, but I\u0027m guessing that window would normally be small since the periodic task by default runs every 10 minutes and we\u0027d still be better off with this change rather than the mess that the power state sync task already gives us, i.e. at a minimum we\u0027re no worse off than we are today.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e663fe47c83f3bd7dfa5070dfcbfaed1331cf3c4","unresolved":false,"context_lines":[{"line_number":81,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":82,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":83,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Alternatives"},{"line_number":86,"context_line":"------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_01f075fc","line":84,"in_reply_to":"5fc1f717_27402f35","updated":"2019-04-09 22:10:25.000000000","message":"+1","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":81,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":82,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":83,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Alternatives"},{"line_number":86,"context_line":"------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_f18f2520","line":84,"in_reply_to":"5fc1f717_27402f35","updated":"2019-04-10 17:30:06.000000000","message":"yea I had my concerns with this too, had briefly discussed this with ironic, jroll had suggested to add a locking mechanism for the first grab:\n\nhttp://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2019-03-25.log.html#t2019-03-25T14:11:04","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            {"},{"line_number":106,"context_line":"                \"name\": \"power-update\","},{"line_number":107,"context_line":"                \"server_uuid\": \"3df201cf-2451-44f2-8d25-a4ca826fc1f3\","},{"line_number":108,"context_line":"                \"tag\": target_power_state"},{"line_number":109,"context_line":"            }"},{"line_number":110,"context_line":"        ]"},{"line_number":111,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0c70b83f","line":108,"updated":"2019-04-09 14:10:54.000000000","message":"OK I guess this answers my question above.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":193,"context_line":"Upgrade impact"},{"line_number":194,"context_line":"--------------"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"None"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Implementation"},{"line_number":199,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0cec38b9","line":196,"updated":"2019-04-09 14:10:54.000000000","message":"If we have compute RPC API version changes for this feature to pass the \u0027call_driver\u0027 parameter to the compute stop_instance/start_instance method, we could hit two cases during a rolling upgrade:\n\n1. The target compute service host for the instance is old and doesn\u0027t understand that new parameter - this should result in a failure so I guess the \"code\" for that event in the response should be a 409 (which would be new for that API I think although technically we should have handled that for volume-extended in 2.51 as well).\n\n2. The compute RPC API version is pinned to a lower version for compatibility, e.g. [upgrade_levels]/compute\u003dstein - in this case you\u0027d get a 409 as well I think since there is a temporary conflict in the state of the resource so we can\u0027t complete the request, but it might work later.\n\nSo will you be handling/checking for either of these in the API? I think we probably should to avoid a weird 500 response during a rolling upgrade (the compute rpcapi client would just raise ServiceTooOld and the API code would handle it and translate to a 409 I think).","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":193,"context_line":"Upgrade impact"},{"line_number":194,"context_line":"--------------"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"None"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Implementation"},{"line_number":199,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_91cca161","line":196,"in_reply_to":"5fc1f717_0cec38b9","updated":"2019-04-10 17:30:06.000000000","message":"oh yea the check completely skipped my mind, thanks for pointing this out. But I think people hate my idea of adding the call_driver flag :( .","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5bad4c5728cb987c5a4d0a6e3e69ec22d3bb4e78","unresolved":false,"context_lines":[{"line_number":245,"context_line":"History"},{"line_number":246,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"Optional section intended to be used each time the spec is updated to describe"},{"line_number":249,"context_line":"new design, API or any database schema updated. Useful to let reader understand"},{"line_number":250,"context_line":"what\u0027s happened along the time."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":".. list-table:: Revisions"},{"line_number":253,"context_line":"   :header-rows: 1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_0c4198a6","line":250,"range":{"start_line":248,"start_character":0,"end_line":250,"end_character":31},"updated":"2019-04-09 14:10:54.000000000","message":"You can remove this template wording.","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"925db15d081e1651d5a5988fe93bacf7efbf94da","unresolved":false,"context_lines":[{"line_number":245,"context_line":"History"},{"line_number":246,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"Optional section intended to be used each time the spec is updated to describe"},{"line_number":249,"context_line":"new design, API or any database schema updated. Useful to let reader understand"},{"line_number":250,"context_line":"what\u0027s happened along the time."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":".. list-table:: Revisions"},{"line_number":253,"context_line":"   :header-rows: 1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fc1f717_31c28d35","line":250,"range":{"start_line":248,"start_character":0,"end_line":250,"end_character":31},"in_reply_to":"5fc1f717_0c4198a6","updated":"2019-04-10 17:30:06.000000000","message":"Done","commit_id":"9399c783bacccfaff2430ab9d93e37da7caa67d9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"291698d9048bd3700d6424be873b149bcedfba1d","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`nova-ironic cross project session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, it will be routed to the ironic driver which will update the"},{"line_number":63,"context_line":"``vm_state`` and ``power_state`` fields of that instance to ``ACTIVE`` and"},{"line_number":64,"context_line":"``RUNNING`` (or ``STOPPED`` and ``SHUTDOWN``) in the nova database. This will"},{"line_number":65,"context_line":"be done using the ``driver.power_update_event`` method that will be added to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_be549acb","line":62,"range":{"start_line":62,"start_character":33,"end_line":62,"end_character":39},"updated":"2019-05-08 19:09:01.000000000","message":"virt.\n\nWe\u0027ll route it to the virt driver, regardless of what is configured. The ironic driver will implement a handler for that, the rest will be NotImplemented (from the base class). We should log an error if we receive a power-update for an instance backed by a virt driver that doesn\u0027t implement that method.","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"4cef21645269166d76dc2cbc284f5b6c8485e1d7","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`nova-ironic cross project session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, it will be routed to the ironic driver which will update the"},{"line_number":63,"context_line":"``vm_state`` and ``power_state`` fields of that instance to ``ACTIVE`` and"},{"line_number":64,"context_line":"``RUNNING`` (or ``STOPPED`` and ``SHUTDOWN``) in the nova database. This will"},{"line_number":65,"context_line":"be done using the ``driver.power_update_event`` method that will be added to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_e14fd331","line":62,"range":{"start_line":62,"start_character":33,"end_line":62,"end_character":39},"in_reply_to":"dfbec78f_be549acb","updated":"2019-05-08 20:15:09.000000000","message":"ah yea that\u0027s what I meant too, I mean it will be a NotImplemented for the rest, but my wordings are not very clear on this. I will update this.","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"291698d9048bd3700d6424be873b149bcedfba1d","unresolved":false,"context_lines":[{"line_number":71,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"},{"line_number":72,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":73,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":74,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_de4f0e32","line":74,"updated":"2019-05-08 19:09:01.000000000","message":"Is this really behavior we want to preserve?","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"4cef21645269166d76dc2cbc284f5b6c8485e1d7","unresolved":false,"context_lines":[{"line_number":71,"context_line":"option ``CONF.compute.allow_power_update_from_ironic`` which will default to"},{"line_number":72,"context_line":"False in order to maintain the present scenario. This means nova will not act"},{"line_number":73,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":74,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_216f2b93","line":74,"in_reply_to":"dfbec78f_de4f0e32","updated":"2019-05-08 20:15:09.000000000","message":"hmm, I am going to nuke this part, we can just make this the default behaviour then. I don\u0027t have any strong reason for keeping this config","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"291698d9048bd3700d6424be873b149bcedfba1d","unresolved":false,"context_lines":[{"line_number":73,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":74,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"},{"line_number":78,"context_line":"and it overrides the ``power-update`` event. However this window is quite"},{"line_number":79,"context_line":"small."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_7e6062a6","line":76,"range":{"start_line":76,"start_character":58,"end_line":76,"end_character":67},"updated":"2019-05-08 19:09:01.000000000","message":"occurrence","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"4cef21645269166d76dc2cbc284f5b6c8485e1d7","unresolved":false,"context_lines":[{"line_number":73,"context_line":"upon any of the events coming from ironic. If the operators want to allow"},{"line_number":74,"context_line":"ironic to be the source of truth this can be set to True."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"},{"line_number":78,"context_line":"and it overrides the ``power-update`` event. However this window is quite"},{"line_number":79,"context_line":"small."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_415a5ff3","line":76,"range":{"start_line":76,"start_character":58,"end_line":76,"end_character":67},"in_reply_to":"dfbec78f_7e6062a6","updated":"2019-05-08 20:15:09.000000000","message":"Done","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"291698d9048bd3700d6424be873b149bcedfba1d","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"},{"line_number":78,"context_line":"and it overrides the ``power-update`` event. However this window is quite"},{"line_number":79,"context_line":"small."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Alternatives"},{"line_number":82,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_5e5d5ee7","line":79,"updated":"2019-05-08 19:09:01.000000000","message":"You could share a lock between the periodic and the event handler...","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"4cef21645269166d76dc2cbc284f5b6c8485e1d7","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Even with this proposed change, depending on the order of occurence of events"},{"line_number":77,"context_line":"we could still have race conditions where the periodic task is already running"},{"line_number":78,"context_line":"and it overrides the ``power-update`` event. However this window is quite"},{"line_number":79,"context_line":"small."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Alternatives"},{"line_number":82,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfbec78f_e1fd93b1","line":79,"in_reply_to":"dfbec78f_5e5d5ee7","updated":"2019-05-08 20:15:09.000000000","message":"yep, it was discussed with jroll and he suggested the same. https://review.opendev.org/#/c/636132/4/specs/train/approved/nova-support-instance-power-update.rst@84, I\u0027ll add this point also.","commit_id":"2da57e4733c60fdac8f6215314b5fb673586720b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"095b19adcf6b89ab9c2b68c38c039d85180bb68b","unresolved":false,"context_lines":[{"line_number":14,"context_line":"``_sync_power_states`` periodic task (which aligns the server states"},{"line_number":15,"context_line":"between the database and the hypervisor) in nova with respect to use cases for"},{"line_number":16,"context_line":"the baremetal instances (ironic). It proposes to make this periodic power"},{"line_number":17,"context_line":"sync\u0027s \"source of truth\" configurable, depending on situations, like to allow"},{"line_number":18,"context_line":"the physical instance to be the source of truth and make nova update its"},{"line_number":19,"context_line":"database rather than enforcing the database state onto the physical instance."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_21c5f95b","line":17,"range":{"start_line":17,"start_character":25,"end_line":17,"end_character":62},"updated":"2019-05-22 02:27:43.000000000","message":"This should also be removed in a follow up since we\u0027re not doing a config option.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"4a65be402338363361b189cc2f975355a140744d","unresolved":false,"context_lines":[{"line_number":36,"context_line":"Note that ironic allows a node to be put into the ``maintenance mode`` by which"},{"line_number":37,"context_line":"that `node will be excluded`_ from nova\u0027s ``_sync_power_states`` periodic task."},{"line_number":38,"context_line":"This covers predictable events like scheduled repairs but does not help with"},{"line_number":39,"context_line":"unforseen events such as power failures."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Use Cases"},{"line_number":42,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_3c953be5","line":39,"range":{"start_line":39,"start_character":0,"end_line":39,"end_character":40},"updated":"2019-05-20 21:06:57.000000000","message":"Isn\u0027t that the whole point of the periodic task? To do things like bringing VMs back online after a power failure?","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5634af1f501fa7bba7e21e5bba147477ae207bda","unresolved":false,"context_lines":[{"line_number":36,"context_line":"Note that ironic allows a node to be put into the ``maintenance mode`` by which"},{"line_number":37,"context_line":"that `node will be excluded`_ from nova\u0027s ``_sync_power_states`` periodic task."},{"line_number":38,"context_line":"This covers predictable events like scheduled repairs but does not help with"},{"line_number":39,"context_line":"unforseen events such as power failures."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Use Cases"},{"line_number":42,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_ea27d563","line":39,"range":{"start_line":39,"start_character":0,"end_line":39,"end_character":40},"in_reply_to":"bfb3d3c7_3c953be5","updated":"2019-05-20 22:17:20.000000000","message":"Not really, it\u0027s more for a crash type event. Either way, the whole point here is that some hardware monkey goes into the lab to replace a system, and nova keeps powering it up while he\u0027s working on it. It\u0027s a little different from a VM.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"e9c608e5832b754e66f98348871b24442118b492","unresolved":false,"context_lines":[{"line_number":58,"context_line":"using the existing external-events API endpoint as discussed in the"},{"line_number":59,"context_line":"`nova-ironic cross project session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, it will be routed to the virt driver. In the virt driver we will add a"},{"line_number":63,"context_line":"new ``driver.power_update_event`` method which will be in a ``NotImplemented``"},{"line_number":64,"context_line":"state for all driver types except ironic. So if we receive a power-update for"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dfbec78f_641088a9","line":61,"updated":"2019-05-13 19:15:04.000000000","message":"Q: What is its in the locked state ?\n\nA: Even then we listen to ironic.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b637cda816c70c1e364979a88326d02a824cf383","unresolved":false,"context_lines":[{"line_number":58,"context_line":"using the existing external-events API endpoint as discussed in the"},{"line_number":59,"context_line":"`nova-ironic cross project session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, it will be routed to the virt driver. In the virt driver we will add a"},{"line_number":63,"context_line":"new ``driver.power_update_event`` method which will be in a ``NotImplemented``"},{"line_number":64,"context_line":"state for all driver types except ironic. So if we receive a power-update for"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_7fd96c81","line":61,"in_reply_to":"dfbec78f_641088a9","updated":"2019-05-20 15:41:08.000000000","message":"Locked doesn\u0027t really mean anything to the layers below the API. Even if an instance is locked, I could shut down the compute host (in the virt case) and affect the state. So, no need to even mention that, IMHO.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"812c5e03e20d43623df7cfc091fee8a3c99649e5","unresolved":false,"context_lines":[{"line_number":58,"context_line":"using the existing external-events API endpoint as discussed in the"},{"line_number":59,"context_line":"`nova-ironic cross project session at the Denver2018 PTG`_."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"On the nova side, once such an event for a physical instance is received from"},{"line_number":62,"context_line":"ironic, it will be routed to the virt driver. In the virt driver we will add a"},{"line_number":63,"context_line":"new ``driver.power_update_event`` method which will be in a ``NotImplemented``"},{"line_number":64,"context_line":"state for all driver types except ironic. So if we receive a power-update for"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dfbec78f_cf186d1f","line":61,"in_reply_to":"dfbec78f_641088a9","updated":"2019-05-13 19:41:11.000000000","message":"s/is/if","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"095b19adcf6b89ab9c2b68c38c039d85180bb68b","unresolved":false,"context_lines":[{"line_number":66,"context_line":"driver this method will update the ``vm_state`` and ``power_state`` fields of"},{"line_number":67,"context_line":"that instance to ``ACTIVE`` and ``RUNNING`` (or ``STOPPED`` and ``SHUTDOWN``)"},{"line_number":68,"context_line":"in the nova database. Note that before routing the call to the driver the"},{"line_number":69,"context_line":"notifications and instance actions for the power update will be handled by nova"},{"line_number":70,"context_line":"similar to the normal start/stop operations."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Even with this proposed change, depending on the order of occurrence of events"},{"line_number":73,"context_line":"we could still have race conditions where the periodic task is already running"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_61cbf171","line":70,"range":{"start_line":69,"start_character":0,"end_line":70,"end_character":44},"updated":"2019-05-22 02:27:43.000000000","message":"++ makes sense","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"c0194dbb91abb34193f1ddbca89a48694db39048","unresolved":false,"context_lines":[{"line_number":139,"context_line":"code"},{"line_number":140,"context_line":"  Event result code. Possible values:"},{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dfbec78f_e9ed31b7","line":142,"range":{"start_line":142,"start_character":6,"end_line":142,"end_character":57},"updated":"2019-05-13 18:16:26.000000000","message":"also if the tag is invalid, it will be the same error code 400.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"796f947c08be6b065a96b2752194179a179d6ebe","unresolved":false,"context_lines":[{"line_number":139,"context_line":"code"},{"line_number":140,"context_line":"  Event result code. Possible values:"},{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_5a12765a","line":142,"range":{"start_line":142,"start_character":6,"end_line":142,"end_character":57},"in_reply_to":"bfb3d3c7_1fbf10fc","updated":"2019-05-20 16:20:38.000000000","message":"ack.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b637cda816c70c1e364979a88326d02a824cf383","unresolved":false,"context_lines":[{"line_number":139,"context_line":"code"},{"line_number":140,"context_line":"  Event result code. Possible values:"},{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_1fbf10fc","line":142,"range":{"start_line":142,"start_character":6,"end_line":142,"end_character":57},"in_reply_to":"dfbec78f_e9ed31b7","updated":"2019-05-20 15:41:08.000000000","message":"Er, I\u0027m not sure this matches with the rest of the events. I think we check the tag only in the context of the proper handler, IIRC. Not sure the API needs to validate this really. TBH, the tag isn\u0027t really needed here, or could be something like the actual new power state of the machine. In that case, it might be driver-specific and thus the API shouldn\u0027t be in the business of policing it.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"4a65be402338363361b189cc2f975355a140744d","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."},{"line_number":146,"context_line":"server_uuid"},{"line_number":147,"context_line":"  Same value as provided in original request."},{"line_number":148,"context_line":"tag"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_3c4c5b9d","line":145,"range":{"start_line":144,"start_character":58,"end_line":145,"end_character":37},"updated":"2019-05-20 21:06:57.000000000","message":"Sorry, how is this different from \"server could not be found\"?","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5634af1f501fa7bba7e21e5bba147477ae207bda","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."},{"line_number":146,"context_line":"server_uuid"},{"line_number":147,"context_line":"  Same value as provided in original request."},{"line_number":148,"context_line":"tag"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_4ad86152","line":145,"range":{"start_line":144,"start_character":58,"end_line":145,"end_character":37},"in_reply_to":"bfb3d3c7_3c4c5b9d","updated":"2019-05-20 22:17:20.000000000","message":"An instance in pre-scheduling, or got somehow orphaned from a compute during a has ring reshuffle, or ended up on a brand new host that isn\u0027t mapped yet but the ironic drivers have already rebalanced the hash ring. I think exhaustive documentation of the meanings of these can be handled in API docs. Specs are not the place that an api consumer should look for documentation on how to use a thing, IMHO.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2e020c1cd4a93f883e1b7aa30e9ddb57ccf35920","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    * 200 means accepted"},{"line_number":142,"context_line":"    * 400 means the request is missing required parameter"},{"line_number":143,"context_line":"    * 404 means the server could not be found"},{"line_number":144,"context_line":"    * 422 means the event cannot be processed because the instance was found"},{"line_number":145,"context_line":"      to not be associated to a host."},{"line_number":146,"context_line":"server_uuid"},{"line_number":147,"context_line":"  Same value as provided in original request."},{"line_number":148,"context_line":"tag"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_d3bf1ef9","line":145,"range":{"start_line":144,"start_character":58,"end_line":145,"end_character":37},"in_reply_to":"bfb3d3c7_4ad86152","updated":"2019-05-21 14:06:14.000000000","message":"Yeah, I agree, I just didn\u0027t understand the difference in what happens under the covers to trigger 404 vs 422. (More to the point, does the user understand/care? But if this is something we already do elsewhere, fine.)","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"801f938ca056be861bc19b2cb4ed7d829d491b94","unresolved":false,"context_lines":[{"line_number":148,"context_line":"tag"},{"line_number":149,"context_line":"  Same value as provided in original request."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"This powering up/down of instances on the nova side will be made visible"},{"line_number":152,"context_line":"through the ``GET /servers/{server_id}/os-instance-actions`` and"},{"line_number":153,"context_line":"``GET /servers/{server_id}/os-instance-actions/{request_id}`` API calls for the"},{"line_number":154,"context_line":"users (by default admins and owners of the server)."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Security impact"},{"line_number":157,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_5fe261d7","line":154,"range":{"start_line":151,"start_character":0,"end_line":154,"end_character":51},"updated":"2019-05-20 21:29:16.000000000","message":"Probably just a lack of background, but I don\u0027t understand this part. Will new instance actions be available that weren\u0027t available before? Which ones specifically?","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5634af1f501fa7bba7e21e5bba147477ae207bda","unresolved":false,"context_lines":[{"line_number":148,"context_line":"tag"},{"line_number":149,"context_line":"  Same value as provided in original request."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"This powering up/down of instances on the nova side will be made visible"},{"line_number":152,"context_line":"through the ``GET /servers/{server_id}/os-instance-actions`` and"},{"line_number":153,"context_line":"``GET /servers/{server_id}/os-instance-actions/{request_id}`` API calls for the"},{"line_number":154,"context_line":"users (by default admins and owners of the server)."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Security impact"},{"line_number":157,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_aae6bd15","line":154,"range":{"start_line":151,"start_character":0,"end_line":154,"end_character":51},"in_reply_to":"bfb3d3c7_5fe261d7","updated":"2019-05-20 22:17:20.000000000","message":"She means that if ironic tells nova that a machine should be shut down (because it is) that we won\u0027t skip the step of putting an instance action in the record so that the user can look at that and see that indeed something requested that the instance be shut down.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"b5ef86a8bfa96c762d46dd5011a01aeeb84fc27a","unresolved":false,"context_lines":[{"line_number":148,"context_line":"tag"},{"line_number":149,"context_line":"  Same value as provided in original request."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"This powering up/down of instances on the nova side will be made visible"},{"line_number":152,"context_line":"through the ``GET /servers/{server_id}/os-instance-actions`` and"},{"line_number":153,"context_line":"``GET /servers/{server_id}/os-instance-actions/{request_id}`` API calls for the"},{"line_number":154,"context_line":"users (by default admins and owners of the server)."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Security impact"},{"line_number":157,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_acaed22b","line":154,"range":{"start_line":151,"start_character":0,"end_line":154,"end_character":51},"in_reply_to":"bfb3d3c7_aae6bd15","updated":"2019-05-21 11:18:36.000000000","message":"yep what Dan said.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2e020c1cd4a93f883e1b7aa30e9ddb57ccf35920","unresolved":false,"context_lines":[{"line_number":148,"context_line":"tag"},{"line_number":149,"context_line":"  Same value as provided in original request."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"This powering up/down of instances on the nova side will be made visible"},{"line_number":152,"context_line":"through the ``GET /servers/{server_id}/os-instance-actions`` and"},{"line_number":153,"context_line":"``GET /servers/{server_id}/os-instance-actions/{request_id}`` API calls for the"},{"line_number":154,"context_line":"users (by default admins and owners of the server)."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Security impact"},{"line_number":157,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_b3d5ca45","line":154,"range":{"start_line":151,"start_character":0,"end_line":154,"end_character":51},"in_reply_to":"bfb3d3c7_acaed22b","updated":"2019-05-21 14:06:14.000000000","message":"++","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"4a65be402338363361b189cc2f975355a140744d","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_dc73bfe6","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"updated":"2019-05-20 21:06:57.000000000","message":"What config option? This isn\u0027t mentioned anywhere else.\n\nFTR, what I was expecting was a config option allowing me to say *which* operation(s) should override the db states. So that I can say \"when my instance comes up, don\u0027t shut it down; but if my instance goes down, please do start it up\". You would need a way to switch the latter off when you\u0027re going to do expected maintenance (mutable config, once SIGHUP is fixed??).\n\nMaybe that\u0027s all too complex.\n\nBut anyway, I think this spec should describe the config option, even if it\u0027s just a boolean to toggle the new behavior.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a83e32efabeeb94f4790c7044a1d09f19b49e9ff","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_c5c20286","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"in_reply_to":"bfb3d3c7_4ac14154","updated":"2019-05-20 23:37:36.000000000","message":"So... there\u0027s no config option? This will always be the behavior for ironic nodes?","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2e020c1cd4a93f883e1b7aa30e9ddb57ccf35920","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_f316e2f1","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"in_reply_to":"bfb3d3c7_8c6c2e37","updated":"2019-05-21 14:06:14.000000000","message":"Okay.\n\nI guess I might have argued to make the \"please power back on in the case of power failure\" a configurable option. But if this is what was decided, so be it.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"a6fca46affdbbf5725377e9ab1045af1dabdbea4","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_8c6c2e37","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"in_reply_to":"bfb3d3c7_c5c20286","updated":"2019-05-21 11:14:18.000000000","message":"\u003e So... there\u0027s no config option? This will always be the behavior\n \u003e for ironic nodes?\n\nexactly. see https://review.opendev.org/#/c/636132/2/specs/train/approved/nova-support-instance-power-update.rst@81 and https://review.opendev.org/#/c/636132/6/specs/train/approved/nova-support-instance-power-update.rst@74 parts of the spec review history.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5634af1f501fa7bba7e21e5bba147477ae207bda","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_4ac14154","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"in_reply_to":"bfb3d3c7_dc73bfe6","updated":"2019-05-20 22:17:20.000000000","message":"I believe this is residue from a previous patch set (as is the reference to it in the early paragraphs). I\u0027m happy for this to be a follow-up nit cleanup patch as we\u0027ve kinda had Surya on hold with this for too long already, IMHO.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"80f961d33c7c3edb568cf28f182dd6b7a56f3533","unresolved":false,"context_lines":[{"line_number":206,"context_line":"#. Add the new external-event type."},{"line_number":207,"context_line":"#. Make the necessary changes in the compute API and manager for the update of"},{"line_number":208,"context_line":"   the power and vm states of the instance on receiving an event from ironic."},{"line_number":209,"context_line":"#. Add the new microversion and config option."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Dependencies"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfb3d3c7_132856e0","line":209,"range":{"start_line":209,"start_character":32,"end_line":209,"end_character":45},"in_reply_to":"bfb3d3c7_f316e2f1","updated":"2019-05-21 14:16:32.000000000","message":"Yeah, let\u0027s remove this in a follow-up :)","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b637cda816c70c1e364979a88326d02a824cf383","unresolved":false,"context_lines":[{"line_number":217,"context_line":"Testing"},{"line_number":218,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Unit and functional tests to verify the new ``power-update`` event\u0027s working."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"Documentation Impact"},{"line_number":223,"context_line":"\u003d\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":7,"id":"bfb3d3c7_7f472c1f","line":220,"range":{"start_line":220,"start_character":36,"end_line":220,"end_character":68},"updated":"2019-05-20 15:41:08.000000000","message":"Femtonit: This should, IMHO be:\n\n \"that the new ``power-update`` event is working.\"\n\n(sorry)","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"796f947c08be6b065a96b2752194179a179d6ebe","unresolved":false,"context_lines":[{"line_number":217,"context_line":"Testing"},{"line_number":218,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Unit and functional tests to verify the new ``power-update`` event\u0027s working."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"Documentation Impact"},{"line_number":223,"context_line":"\u003d\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":7,"id":"bfb3d3c7_fa2c8a9a","line":220,"range":{"start_line":220,"start_character":36,"end_line":220,"end_character":68},"in_reply_to":"bfb3d3c7_7f472c1f","updated":"2019-05-20 16:20:38.000000000","message":"hehe yea flaws of a non-native English speaker.","commit_id":"ea92251c442cd2412a75c148a04a271bd386f98f"}]}