)]}'
{"specs/approved/deploy-fail-to-active.rst":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"85e23e5f6b9a8d8b2164a990c981dc394eacba08","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_51e31806","line":51,"updated":"2020-10-30 09:41:11.000000000","message":"I cannot agree with this point. We can and should verify that no destructive actions have been done to the node. If we allow this literally, and a node fails while connected to the provisioning network, a user will be able to run their code on the provisioning network by powering the machine back on. This is a security hazard.","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"1a42f524fdc9b1d0d90e8dc0abcf4aedec1186e2","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d9e99fb2_6abc9fd3","line":51,"in_reply_to":"1ec0c946_57a1c3ce","updated":"2021-01-26 15:12:49.000000000","message":"wrt downstream patch: yes, of course that is possible. The whole idea of this spec etc is to do something upstream (if upstream WANTS it) so that others can also use it.\n\nwrt permit in maintenance mode: sure. What exactly though is the flow? Node is in \u0027deploy failed\u0027, admin puts in maintenance, admin issues X to put node in \u0027active\u0027, admin removes from maintenance?\n\nwrt checking if IPA (or some other deploy driver) has started. Yes, this is do-able.\n\nwrt recovery. I\u0027d consider that outside the scope of this spec (eg phase 2), unless people feel like we can\u0027t do this without a recovery mechanism.\n\n(One thing that bothers me, is that ironic doesn\u0027t actually keep info about the bm node wrt what it KNOWS about it. eg, ironic uses instance_info to deploy, but then that info could be changed and we don\u0027t know what was used for the actual deployment. I suppose if we had some audit trail, it could be figured out.)","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"aa47da93afc4e4f3f381b6aa934a4109960025af","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_792b68ea","line":51,"in_reply_to":"1f621f24_51e31806","updated":"2020-11-03 21:59:54.000000000","message":"Sure. I believe we mentioned this at the PTG when we discussed this feature. What verification do you suggest that we do in code? I was afraid of rabbit-holing here. Whatever we do, I still think we might want this caveat.\n\nI looked at the nova \u0027equivalent\u0027 and it doesn\u0027t do any checking/validation.","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"ca8f7410450c30391aebcee8762e28b42fd20445","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b11e8c04_18b958ae","line":51,"in_reply_to":"1f621f24_791a487d","updated":"2020-12-04 21:47:38.000000000","message":"This is explicitly an action designed for handling error cases. I don\u0027t think the security hazard argument necessarily applies to an admin action that overrides normal  Ironic behavior -- since the sheer need to run this would indicate a failure in Ironic.\n\nSome basic sanity checking might be nice, but we should not force operators to perform drastic actions, or interact with the DB, to recover from a failure scenario. Today, that\u0027s not true for cases where Nova rebuilds fail in certain ways.","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"fc1e6c75d9fdcbb34c51d12134dc359ef2df32c1","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_791a487d","line":51,"in_reply_to":"1f621f24_792b68ea","updated":"2020-11-03 22:14:32.000000000","message":"I see in the story, that Dmitry mentioned \u0027safe guards/recovery actions in this case (e.g. if we change the boot device DISK-\u003ePXE, we need to change it back, etc\u0027\n\nWe should definitely discuss. I had briefly thought about this, but to do it well? means taking a \u0027snapshot\u0027 of the node\u0027s settings? before the rebuild happens. even the instance/image information could have changed during the rebuild. Dmitry is probably right, people will shoot themselves in the feet... hmm. this won\u0027t work. nova sets/updates the instance info before ironic does a rebuild, so ironic won\u0027t know to save any info before it does the rebuild unless ironic always backs up the instance info. Let\u0027s see how many people really want this feature and how hardened they want it to be...","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"6eadbaa65d21db20dd6debab419940b44cfc16e8","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ec0c946_57a1c3ce","line":51,"in_reply_to":"b11e8c04_18b958ae","updated":"2021-01-25 17:57:02.000000000","message":"A counter-statement: an operator who knows ironic so deeply to understand when it\u0027s safe or not is capable of a downstream patch. Or we can permit it in maintenance mode (as we do for some actions).\n\nAs a first step here we can check if IPA has started on the node (by the presence of temporary fields). This is probably good enough for most cases.\n\nThen we have a question of recovery, which is actually more problematic. We need to restore: boot device, boot mode and secure boot status, as well as restore PXE configuration if the instance is network booting. This essentially calls for a new transient state (\"restoring\"?).","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"08261be885e3771770fb976b723fc238b06b4d0b","unresolved":false,"context_lines":[{"line_number":48,"context_line":"There is a policy for access to this API."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"*The onus is on humans or something outside of ironic, to verify that"},{"line_number":51,"context_line":"it is safe to do this.*"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Proposed change"},{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ba4aa848_546af453","line":51,"in_reply_to":"d9e99fb2_6abc9fd3","updated":"2021-01-26 16:00:11.000000000","message":"If we don\u0027t do recovery, we\u0027re pretty much doomed to leave a node in a state in which it won\u0027t survive the next reboot. I don\u0027t feel well creating a feature that only you and Jay can use reliably.\n\nIf it was an ironic-dbsync command, I would not object, but I guess you want to integrate it with nova?\n\nFinally, I don\u0027t think we should account for the case \"admin set instance_info to some non-sense\".","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"ca8f7410450c30391aebcee8762e28b42fd20445","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The changes required to support this new API:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"- Since ironic\u0027s provisioning state diagram doesn\u0027t capture whether a rebuild"},{"line_number":59,"context_line":"  operation is occurring, in order to know whether it is a rebuild (versus an"},{"line_number":60,"context_line":"  initial deployment), the node\u0027s \"driver_internal_info\" will be updated to"},{"line_number":61,"context_line":"  include whether a rebuild operation is being performed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"763a3410_6d168149","line":58,"updated":"2020-12-04 21:47:38.000000000","message":"ironic should be capitalized throughout","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"85e23e5f6b9a8d8b2164a990c981dc394eacba08","unresolved":false,"context_lines":[{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Allowing nodes to go from \"deploy failed\" to \"active\" should be reflected"},{"line_number":112,"context_line":"in our state machine diagram. We\u0027ll add an \"active-reset\" verb"},{"line_number":113,"context_line":"from \"deploy failed\" to \"active\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"REST API impact"},{"line_number":116,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_b1f0accb","line":113,"updated":"2020-10-30 09:41:11.000000000","message":"I\u0027d slightly prefer to use just \"active\" instead of inventing a new verb.","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"aa47da93afc4e4f3f381b6aa934a4109960025af","unresolved":false,"context_lines":[{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Allowing nodes to go from \"deploy failed\" to \"active\" should be reflected"},{"line_number":112,"context_line":"in our state machine diagram. We\u0027ll add an \"active-reset\" verb"},{"line_number":113,"context_line":"from \"deploy failed\" to \"active\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"REST API impact"},{"line_number":116,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_b90ea08a","line":113,"in_reply_to":"1f621f24_b1f0accb","updated":"2020-11-03 21:59:54.000000000","message":"My concern with \u0027active\u0027 is due to the caveat I put above, about user-admin-beware. I wanted to be explicit that it was a \u0027reset of state\u0027 vs \u0027guaranteed, ironic is moving it to that state cuz ironic knows it is ok to be active\u0027.\n\nAnother reason for not using \u0027active\u0027 is because \u0027active\u0027 is already used to move nodes in \u0027deploy failed\u0027 to \u0027deploying\u0027 [1]. I am not sure we should use the same verb to do two diff things depending on something else, although that is possible (the user would have to indicate that they want the node to be \u0027active\u0027 and skip deploying on the way there? Thoughts?\n\n[1] https://docs.openstack.org/ironic/latest/_images/states.svg","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"85e23e5f6b9a8d8b2164a990c981dc394eacba08","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Nothing (at this time) is planned for proposing that nova enhance"},{"line_number":164,"context_line":"its current \u0027openstack compute reset -active\u0027 to call this new"},{"line_number":165,"context_line":"command in ironic."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This means that the onus is on humans (the administrator) to make sure"},{"line_number":168,"context_line":"that the nova instance\u0027s states are in sync with its corresponding"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_91edb0f1","line":165,"updated":"2020-10-30 09:41:11.000000000","message":"Why not? Is it impossible?","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"aa47da93afc4e4f3f381b6aa934a4109960025af","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Nothing (at this time) is planned for proposing that nova enhance"},{"line_number":164,"context_line":"its current \u0027openstack compute reset -active\u0027 to call this new"},{"line_number":165,"context_line":"command in ironic."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"This means that the onus is on humans (the administrator) to make sure"},{"line_number":168,"context_line":"that the nova instance\u0027s states are in sync with its corresponding"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f621f24_597cacea","line":165,"in_reply_to":"1f621f24_91edb0f1","updated":"2020-11-03 21:59:54.000000000","message":"I doubt that it is impossible. It means engaging with nova etc. Which I don\u0027t plan on doing right now cuz I\u0027m short of time :) Whatever we do to hook up with nova, I don\u0027t think the ironic API part would change.\n\nWould you like me to reword it somehow? eg. \u0027It may be possible to have nova enhanced to call this new API, but that will not be done in this first phase\u0027 ?","commit_id":"4e7af74770dd264b3f31372085587cbe9236ed16"}]}