)]}'
{"specs/kilo/new-ironic-state-machine.rst":[{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"A proposal for the new Ironic system lifecycle state machine."},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7c652ee0","line":7,"updated":"2014-11-11 21:14:14.000000000","message":"These lines need to the be full length of the title for the sphinx build to succeed (i.e. for the docs to build).","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1103960b2cd75ee3aeed93e39b7c64e39fb963dc","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"A proposal for the new Ironic system lifecycle state machine."},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_878c3537","line":7,"in_reply_to":"5a890539_7c652ee0","updated":"2014-11-12 12:07:40.000000000","message":"+1","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1103960b2cd75ee3aeed93e39b7c64e39fb963dc","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"A proposal for the new Ironic system lifecycle state machine."},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/new-ironic-state-machine"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_e77c1923","line":8,"updated":"2014-11-12 12:07:40.000000000","message":"This should be the name New Ironic State Machine","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"A proposal for the new Ironic system lifecycle state machine."},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/new-ironic-state-machine"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_59aceda0","line":8,"in_reply_to":"5a890539_e77c1923","updated":"2014-11-12 15:22:38.000000000","message":"Done","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":34,"context_line":"  get it, so running these tasks as part of DEPLOYING or DEPLOYWAIT is nonviable."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":37,"context_line":"  decomissioning blueprints handle this in DELETING, but it would also be"},{"line_number":38,"context_line":"  useful to perform decomissioning tasks on freshly-added nodes."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* We also need to let external orchestration systems hook into parts of the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_bc5f960d","line":37,"updated":"2014-11-11 21:14:14.000000000","message":"This is false, the current blueprints suggest adding DECOMMISSIONING and DECCOMISSIONED states.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":34,"context_line":"  get it, so running these tasks as part of DEPLOYING or DEPLOYWAIT is nonviable."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":37,"context_line":"  decomissioning blueprints handle this in DELETING, but it would also be"},{"line_number":38,"context_line":"  useful to perform decomissioning tasks on freshly-added nodes."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* We also need to let external orchestration systems hook into parts of the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_59830d04","line":37,"in_reply_to":"5a890539_bc5f960d","updated":"2014-11-12 15:22:38.000000000","message":"Done","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"87c755a024d80b6a86d03fbd04179a6c02d898d9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  provisioner state transitions are to DISCOVERING (if the node was enrolled"},{"line_number":54,"context_line":"  as a side effect of booting to a discovery image that knows how to talk to"},{"line_number":55,"context_line":"  Ironic), and INIT (if the node is being created via the API without a"},{"line_number":56,"context_line":"  discovery image)."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7cc1ae7f","line":56,"updated":"2014-11-11 21:10:19.000000000","message":"I guess, node created manually may enter \u0027init\u0027 right away, if all fields are set in the \u0027create\u0027 request.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  provisioner state transitions are to DISCOVERING (if the node was enrolled"},{"line_number":54,"context_line":"  as a side effect of booting to a discovery image that knows how to talk to"},{"line_number":55,"context_line":"  Ironic), and INIT (if the node is being created via the API without a"},{"line_number":56,"context_line":"  discovery image)."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_5cca3250","line":56,"in_reply_to":"5a890539_7cc1ae7f","updated":"2014-11-11 21:36:30.000000000","message":"ya, although I would envision that the API call flow would look like node create (with optional added parameters) -\u003e here is your new node UUID -\u003e set shiny new node to INIT -\u003e OK, party on wayne.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"7ab31fdd1868b8e3fe2f065f33594f44cf3cb366","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  Ironic), and INIT (if the node is being created via the API without a"},{"line_number":56,"context_line":"  discovery image)."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_b9a31f4e","line":58,"updated":"2014-11-12 07:52:14.000000000","message":"there should be DISCOVERFAIL as well e.g. in case of timeout","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"87c755a024d80b6a86d03fbd04179a6c02d898d9","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_9cbe5afe","line":60,"updated":"2014-11-11 21:10:19.000000000","message":"Node is not \"enrolled as a side effect being booted to via a discovery image\", it\u0027s still 2 separate actions: create (state\u003dENROLL), discover (state\u003dDISCOVERING)","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_590dcd8f","line":60,"in_reply_to":"5a890539_7999b71e","updated":"2014-11-12 15:22:38.000000000","message":"OK, that is not how I was envisioning discovery working at all, as it implies that Ironic knows about the node before the discovery process starts.  Ptr to discovery specs?","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"7ab31fdd1868b8e3fe2f065f33594f44cf3cb366","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7999b71e","line":60,"in_reply_to":"5a890539_7cf52e82","updated":"2014-11-12 07:52:14.000000000","message":"Well, with the current proposals it is:\n\nOOB: set to \"discovering\" -\u003e call BMC -\u003e update -\u003e set to \"init\"\n\nIB: set to \"discovering\" -\u003e call discoverd -\u003e discoverd boots ramdisk, receives response, updates node, sets to \"init\"\n\nanyway state \"discovering\" should be set before calling to discoverd.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"DISCOVERING"},{"line_number":59,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7cf52e82","line":60,"in_reply_to":"5a890539_9cbe5afe","updated":"2014-11-11 21:36:30.000000000","message":"Indeed, I envision the flow there as (starting from booting from the discovery image):\nIs there a node matching {blob} -\u003e Nope -\u003e  THere should be: create a new node -\u003e OK, Here is your new node UUID -\u003e Great, now set its state to DISCOVERING and I will get back to you with more settings","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"87c755a024d80b6a86d03fbd04179a6c02d898d9","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":65,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_5c4b122b","line":63,"updated":"2014-11-11 21:10:19.000000000","message":"\u003e pick the appropriate set of drivers to manage the node\n\nI don\u0027t think we have agreement on this. All variants of discovery proposed up until now require a driver to be already set. Can we postpone it for future work?","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":65,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_bc46b6bd","line":63,"in_reply_to":"5a890539_5c4b122b","updated":"2014-11-11 21:36:30.000000000","message":"Maybe, depends on how persuasive others can be.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":65,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_f9a59947","line":63,"in_reply_to":"5a890539_87999521","updated":"2014-11-12 15:22:38.000000000","message":"Ugh, allowing conductors to have different drivers loaded/enabled sounds like an antipattern to me, along with distributing responsibility for nodes in the ring based on the drivers that a node is using.  Why not distribute nodes in the ring based strictly on node UUID and enforce that all conductors have the same drivers loaded?  That would neatly avoid weird failure conditions caused by conductor failures talking out the ability to (for example) talk to an ilo, and set the stage for allowing per-node drivers to be dynamic and composable.\n\nBut I am ratholing.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1103960b2cd75ee3aeed93e39b7c64e39fb963dc","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":61,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":65,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_87999521","line":63,"in_reply_to":"5a890539_bc46b6bd","updated":"2014-11-12 12:07:40.000000000","message":"I also was assuming (for the first version of it at least) that Nodes would have a known driver already set.\n\nI see this thing about finding out which driver the node should use automatically as a big ball of wax, first because conductors may have different drivers loaded/enabled, so it would differ depending on which conductor is managing the node (which is automatically assigned by Ironic), second is that it will require core changes to the way the hash ring works nowadays, right now we create a ring per driver and therefor we can\u0027t have a node with no driver, otherwise it wouldn\u0027t be managed by any conductor.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"87c755a024d80b6a86d03fbd04179a6c02d898d9","unresolved":false,"context_lines":[{"line_number":62,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":63,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":65,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"INIT"},{"line_number":68,"context_line":"  Once a node has an initial set of drivers and enough configuration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_9c557ac8","line":65,"updated":"2014-11-11 21:10:19.000000000","message":"+1, this is one of the reasons we need \"DISCOVERING\" state","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"87c755a024d80b6a86d03fbd04179a6c02d898d9","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":69,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":70,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":71,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"},{"line_number":72,"context_line":"  INIT state, an API caller can either transition the node to AVAILABLE, or"},{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_3c5e46e7","line":71,"updated":"2014-11-11 21:10:19.000000000","message":"I expected INIT to be entered automatically after successful discovery. It is _leaving_ INIT state (via ZAPPING to AVAILABLE) that should be done by user\u0027s intervention.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"7ab31fdd1868b8e3fe2f065f33594f44cf3cb366","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":69,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":70,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":71,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"},{"line_number":72,"context_line":"  INIT state, an API caller can either transition the node to AVAILABLE, or"},{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_f984c7b2","line":71,"in_reply_to":"5a890539_1c0d0a91","updated":"2014-11-12 07:52:14.000000000","message":"then I didn\u0027t understand what you mean by \"Ironic should not do this by itself\"","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":69,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":70,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":71,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"},{"line_number":72,"context_line":"  INIT state, an API caller can either transition the node to AVAILABLE, or"},{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_1c0d0a91","line":71,"in_reply_to":"5a890539_3c5e46e7","updated":"2014-11-11 21:36:30.000000000","message":"IIRC, that is what I wrote.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":69,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":70,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":71,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"},{"line_number":72,"context_line":"  INIT state, an API caller can either transition the node to AVAILABLE, or"},{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_9c3ac3cb","line":71,"in_reply_to":"5a890539_f984c7b2","updated":"2014-11-12 15:22:38.000000000","message":"I mean exactly what I said: \"Nodes must be transitioned out of INIT by an API call\", and \"Ironic should not do this by itself\" clarifies that Ironic must not transition a node out of INIT unless there is an API call that explicitly does so.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":"  * securely erasing disks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7cac4eee","line":76,"updated":"2014-11-11 21:14:14.000000000","message":"Can we explicitly point out this is where DECOMMISSIONING is expected to happen?","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":"  * securely erasing disks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_bc3cdfc0","line":76,"in_reply_to":"5a890539_7cac4eee","updated":"2014-11-12 15:22:38.000000000","message":"Done","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  queue up destructive and/or long-running tasks and then transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":"  * securely erasing disks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_bc1dd6bf","line":76,"in_reply_to":"5a890539_7cac4eee","updated":"2014-11-11 21:36:30.000000000","message":"Sure.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"66d836b780b7fd2ede56e976623f118ca2b4e163","unresolved":false,"context_lines":[{"line_number":82,"context_line":"  * going through burnin."},{"line_number":83,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":84,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":85,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":86,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"ZAPFAIL"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_bcc5d65c","line":85,"updated":"2014-11-11 22:32:01.000000000","message":"I\u0027d think these will be enqueued at the beginning of ZAPPING based on the available steps from the drivers, hardware capabilities, and config options. At least that\u0027s how I envisioned it. I generally imagine the steps that will occur in zapping will be automatically decided, rather than by operator intervention in the standard case (but running individual steps via API should definitely be allowed).","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"005a79d960979043c3902d8a7d49ce9b4b29ad19","unresolved":false,"context_lines":[{"line_number":82,"context_line":"  * going through burnin."},{"line_number":83,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":84,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":85,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":86,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"ZAPFAIL"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_778629bb","line":85,"in_reply_to":"5a890539_bcc5d65c","updated":"2014-11-11 22:53:53.000000000","message":"Experience with Crowbar has brought me to the conclusion that it is much less ambiguous to separate \"figure out what actions I should take\" states from the \"do it\" states.  However, we didn\u0027t really talk about that aspect of things at the summit.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1103960b2cd75ee3aeed93e39b7c64e39fb963dc","unresolved":false,"context_lines":[{"line_number":88,"context_line":"ZAPFAIL"},{"line_number":89,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"},{"line_number":90,"context_line":"  node to ZAPFAIL, and operator intervention will be required to"},{"line_number":91,"context_line":"  resolve the situation."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"AVAILABLE"},{"line_number":94,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_e20de738","line":91,"updated":"2014-11-12 12:07:40.000000000","message":"Another thing I would add is that when ZAPFAIL occur is that node should also be set to maintenance mode. I think it\u0027s a more clear indication (at least in the Ironic land) that when a node is in maintenance mode it requires the operator to go and check it manually.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"b725cf82b2a5e05fe27cf0025492e298f7bcd5b9","unresolved":false,"context_lines":[{"line_number":88,"context_line":"ZAPFAIL"},{"line_number":89,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"},{"line_number":90,"context_line":"  node to ZAPFAIL, and operator intervention will be required to"},{"line_number":91,"context_line":"  resolve the situation."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"AVAILABLE"},{"line_number":94,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_fc46674e","line":91,"in_reply_to":"5a890539_e20de738","updated":"2014-11-12 15:22:38.000000000","message":"Good point, will add.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":112,"context_line":"  resolve the situation."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"PREBOOT"},{"line_number":115,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":116,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":117,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_3cd00650","line":114,"updated":"2014-11-11 21:14:14.000000000","message":"Long running ramdisks would be left in this state, correct? So nodes in PREBOOT are eligible (and almost preferred) for scheduling, right?","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"66d836b780b7fd2ede56e976623f118ca2b4e163","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":112,"context_line":"  resolve the situation."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"PREBOOT"},{"line_number":115,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":116,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":117,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_57ca0d50","line":114,"in_reply_to":"5a890539_1c842ad3","updated":"2014-11-11 22:32:01.000000000","message":"So going from PREBOOT to DEPLOYING seems wrong to me. Imagine that we have 2 different things that we\u0027d want to preboot (booting an agent and precaching an image to a node) and we want the scheduler to prefer nodes with both (for superfast provision times). We\u0027ll need to save something on the node (probably in node.properties or node.capabilities) once a preboot step is accomplished to differentiate between them. So it seems like leaving the nodes in PREBOOT doesn\u0027t give us anything, and they should transition back to AVAILABLE and only be scheduled to once they are in that state. So basically, nodes should go into PREBOOTING while doing something, PREBOOT when done, then Ironic moves them back to AVAILABLE, and they\u0027re scheduled from there, in my opinion. I think this will simplify the code path for Ironic and the scheduler.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":112,"context_line":"  resolve the situation."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"PREBOOT"},{"line_number":115,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":116,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":117,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_1c842ad3","line":114,"in_reply_to":"5a890539_3cd00650","updated":"2014-11-11 21:36:30.000000000","message":"I don\u0027t know what the consensus at the meeting was on that point, hence the vagueness of this state around that topic.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"005a79d960979043c3902d8a7d49ce9b4b29ad19","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":112,"context_line":"  resolve the situation."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"PREBOOT"},{"line_number":115,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":116,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":117,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7210f74e","line":114,"in_reply_to":"5a890539_57ca0d50","updated":"2014-11-11 22:53:53.000000000","message":"Noted, but I want others to weigh in on this as well.  The use cases I had in mind (using Ironic as a provisioning/server config layer for Crowbar, no Nova involved at all) would go straight from PREBOOT to DEPLOYING because booting to a ramdisk makes it easier for us to not care about the difference between in-band node config (via whatever vendor-specific hardware config tools the platform required) vs. out-of-band node config (via your preferred OOB management interface).","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1103960b2cd75ee3aeed93e39b7c64e39fb963dc","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":112,"context_line":"  resolve the situation."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"PREBOOT"},{"line_number":115,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":116,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":117,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_a2867f63","line":114,"in_reply_to":"5a890539_7210f74e","updated":"2014-11-12 12:07:40.000000000","message":"@Josh, in that use case I would argue whether we should have the PREBOOT state or not, I think it could go from PREBOOTING to AVAIABLE straight away.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":147,"context_line":"  them alone. Nodes in ACTIVE can transition to RESCUE and to DELETING."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"RESCUE"},{"line_number":150,"context_line":"  RESCUE exists to allow Ironic to be aware of a node that would be"},{"line_number":151,"context_line":"  otherwise running a workload, but that has been booted into a"},{"line_number":152,"context_line":"  different environment for some other (usually troubleshooting or"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_9c6c9a9e","line":149,"updated":"2014-11-11 21:14:14.000000000","message":"I wish we had a better place than provision state to indicate rescued machines (like task_state) but given the current setup this makes sense.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":147,"context_line":"  them alone. Nodes in ACTIVE can transition to RESCUE and to DELETING."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"RESCUE"},{"line_number":150,"context_line":"  RESCUE exists to allow Ironic to be aware of a node that would be"},{"line_number":151,"context_line":"  otherwise running a workload, but that has been booted into a"},{"line_number":152,"context_line":"  different environment for some other (usually troubleshooting or"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_9c773a02","line":149,"in_reply_to":"5a890539_9c6c9a9e","updated":"2014-11-11 21:36:30.000000000","message":"There is still the maintenance flag, which I would expect to be used in conjunction with this state.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":160,"context_line":"  should transition to DELETED if teardown was successful, or to"},{"line_number":161,"context_line":"  DELETEFAIL if it was not."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"DELETEFAIL"},{"line_number":164,"context_line":"  If deleting a node fails for some reason, Ironic will transition the"},{"line_number":165,"context_line":"  node to DELETEFAIL, and operator intervention will be required to"},{"line_number":166,"context_line":"  resolve the situation."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_3c1566f1","line":163,"updated":"2014-11-11 21:14:14.000000000","message":"Today, if this happens, nodes go into DEPLOYFAIL iirc. Might be worth noting here? (TBH I\u0027m not 100% sure this is true upstream; it absolutely is true downstream for OnMetal)","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":160,"context_line":"  should transition to DELETED if teardown was successful, or to"},{"line_number":161,"context_line":"  DELETEFAIL if it was not."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"DELETEFAIL"},{"line_number":164,"context_line":"  If deleting a node fails for some reason, Ironic will transition the"},{"line_number":165,"context_line":"  node to DELETEFAIL, and operator intervention will be required to"},{"line_number":166,"context_line":"  resolve the situation."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_1c5b4a88","line":163,"in_reply_to":"5a890539_3c1566f1","updated":"2014-11-11 21:36:30.000000000","message":"Totally worth noting, yes.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"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":"e8313a7ffc0eadc5366d8a2fa167c55ab3adfaec","unresolved":false,"context_lines":[{"line_number":169,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":170,"context_line":"  scrubbed or had certian persistent configuration (such as RAID"},{"line_number":171,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":172,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":173,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":174,"context_line":"  to scrub the system, run it through burnin again, or perform some"},{"line_number":175,"context_line":"  other long-running task)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_3c2c8647","line":172,"updated":"2014-11-11 21:14:14.000000000","message":"Instead of \"if there is no need to scrub the system\" I\u0027d say, if the operator has configured Ironic to skip any cleanup steps. There\u0027s always a need to scrub the system :)","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"59f9c582bf3b353bc468e901b9531a8243218b4a","unresolved":false,"context_lines":[{"line_number":169,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":170,"context_line":"  scrubbed or had certian persistent configuration (such as RAID"},{"line_number":171,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":172,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":173,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":174,"context_line":"  to scrub the system, run it through burnin again, or perform some"},{"line_number":175,"context_line":"  other long-running task)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_7cd8ceef","line":172,"in_reply_to":"5a890539_3c2c8647","updated":"2014-11-11 21:36:30.000000000","message":"For OnMetal, totally.  For using Ironic to manage an undercloud, or some other private thing, you have some other operators to convince.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"66d836b780b7fd2ede56e976623f118ca2b4e163","unresolved":false,"context_lines":[{"line_number":225,"context_line":"Nova driver impact"},{"line_number":226,"context_line":"------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Maybe not."},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"Security impact"},{"line_number":231,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_97f1d5cf","line":228,"updated":"2014-11-11 22:32:01.000000000","message":"Minor change to look for AVAILABLE instead of NOSTATE, which is going to require some extra coding to deal with upgrades, so that Nova can be upgraded independently of Ironic.","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"005a79d960979043c3902d8a7d49ce9b4b29ad19","unresolved":false,"context_lines":[{"line_number":225,"context_line":"Nova driver impact"},{"line_number":226,"context_line":"------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Maybe not."},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"Security impact"},{"line_number":231,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_b21a5f6c","line":228,"in_reply_to":"5a890539_97f1d5cf","updated":"2014-11-11 22:53:53.000000000","message":"Noted, will update for Round 2 (of N)","commit_id":"d5ca3f26aa79ff647ee69b1ecc950ed8174e0586"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"711e42a31f299a03e7fde0eace762c09a6a61993","unresolved":false,"context_lines":[{"line_number":57,"context_line":"  Ironic), and INIT (if the node is being created via the API without a"},{"line_number":58,"context_line":"  discovery image)."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"DISCOVERING"},{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_1c909342","line":60,"updated":"2014-11-12 15:29:49.000000000","message":"also DISCOVERYFAIL please","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"711e42a31f299a03e7fde0eace762c09a6a61993","unresolved":false,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"DISCOVERING"},{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":64,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":65,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_5cde9b40","line":62,"updated":"2014-11-12 15:29:49.000000000","message":"that\u0027s how it\u0027s not proposed to work: https://review.openstack.org/#/c/100951/\n\nalso have a look at discoverd README: https://pypi.python.org/pypi/ironic-discoverd","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"DISCOVERING"},{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":64,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":65,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_ac48a8b3","line":62,"in_reply_to":"5a890539_5cde9b40","updated":"2014-11-17 18:08:46.000000000","message":"Done","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"711e42a31f299a03e7fde0eace762c09a6a61993","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":64,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":65,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":66,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_5c83fb03","line":64,"updated":"2014-11-12 15:29:49.000000000","message":"also see links above","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"8f392089c40e61cacc79ba8ba94dc14ec95d0210","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":64,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":65,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":66,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_66facbbe","line":64,"in_reply_to":"5a890539_5c83fb03","updated":"2014-11-13 11:49:24.000000000","message":"I think that this bit about the discovery image find the appropriated driver responsible to manage the node is a problem. Every node in Ironic (by design) has to have a driver associated with it, the driver is what is used to bound nodes to conductor so the requests to a given node \n\nAlso how would the credentials work here? In order to find out the right driver to manage it + get physical characteristics of it you would need to have a couple of different credentials for different drivers to exist in the node so it can do it.\n\nMy suggestion would be to, at least as a start, to actually assume that the node registered knows which driver will be used to manage it.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  When a node is being enrolled as a side effect being booted to via a"},{"line_number":62,"context_line":"  discovery image, it should immediately transition from ENROLL to"},{"line_number":63,"context_line":"  DISCOVERING. It is expected that the discovery image will populate some"},{"line_number":64,"context_line":"  basic information about the node and pick the appropriate set of drivers"},{"line_number":65,"context_line":"  to manage the node.  Any actions the discovery image takes MUST be"},{"line_number":66,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a node that"},{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_ac8d08d5","line":64,"in_reply_to":"5a890539_66facbbe","updated":"2014-11-17 18:08:46.000000000","message":"OK, I will do that.  Just means that Crowbar will have to handle node discovery and enrollment outside Ironic.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"INIT"},{"line_number":70,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":71,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":72,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":73,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_290b4126","line":70,"updated":"2014-11-12 22:49:20.000000000","message":"s/the power state of//\n\nSome of the things which in-band discovery should provide are disk size (and topology), CPU count, RAM, etc... and eventually more capabilities than that, as well. All of this is necessary to provision the node (eg, make it to AVAILABLE state)","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"8f392089c40e61cacc79ba8ba94dc14ec95d0210","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"INIT"},{"line_number":70,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":71,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":72,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":73,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_c6ed3ff1","line":70,"in_reply_to":"5a890539_290b4126","updated":"2014-11-13 11:49:24.000000000","message":"+1 yeah I wouldn\u0027t say power state explicitly; To be available means that the node should be fully manageable, this includes power state and deploy state, etc...","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  it should not manage, but that got discovered by mistake."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"INIT"},{"line_number":70,"context_line":"  Once a node has an initial set of drivers and enough configuration"},{"line_number":71,"context_line":"  information to allow Ironic to manage the power state of the node, it should"},{"line_number":72,"context_line":"  be placed into INIT and (optionally) powered off.  Nodes must be transitioned"},{"line_number":73,"context_line":"  out of INIT by an API call -- Ironic should not do this by itself.  In the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_0c6d3c04","line":70,"in_reply_to":"5a890539_290b4126","updated":"2014-11-17 18:08:46.000000000","message":"Done","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":113,"context_line":"PREBOOTFAIL"},{"line_number":114,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"},{"line_number":115,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":116,"context_line":"  resolve the situation."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOT"},{"line_number":119,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_490ecd35","line":116,"updated":"2014-11-12 22:49:20.000000000","message":"not sure this blanket statement holds. there are transient issues which we can recover from ...","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":113,"context_line":"PREBOOTFAIL"},{"line_number":114,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"},{"line_number":115,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":116,"context_line":"  resolve the situation."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOT"},{"line_number":119,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_6c2320bd","line":116,"in_reply_to":"5a890539_490ecd35","updated":"2014-11-17 18:08:46.000000000","message":"Right, but I was operating under the assumption that Ironic would rather defer error handling at this level to either and external operator or systems operating on their behalf -- that was the impression I got from Jay, at least.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":118,"context_line":"PREBOOT"},{"line_number":119,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":120,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":121,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":122,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":123,"context_line":"  can also be enqueued on the node from this state."},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_69146944","line":121,"updated":"2014-11-12 22:49:20.000000000","message":"how is this \"maintenance purpose\" tracked?","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":118,"context_line":"PREBOOT"},{"line_number":119,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":120,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":121,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":122,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":123,"context_line":"  can also be enqueued on the node from this state."},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_8f1cbe6b","line":121,"in_reply_to":"5a890539_69146944","updated":"2014-11-17 18:08:46.000000000","message":"In whatever incident-tracking system our customers are using.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"8f392089c40e61cacc79ba8ba94dc14ec95d0210","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":121,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":122,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":123,"context_line":"  can also be enqueued on the node from this state."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"DEPLOYING"},{"line_number":126,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_d73b2a9a","line":123,"updated":"2014-11-13 11:49:24.000000000","message":"Same question as @devananda. Plus, it looks like we are going to have 2 states which the nova scheduler can look at to pick a node: AVAILABLE and PREBOOT, is that correct?\n\nI think I understand the difference trying to be represented here, where PREBOOT would be for a quicker deployment and AVAILABLE may take more time. But wouldn\u0027t it be more sane if after PREDEPLOYING the node is put back to AVAILABLE state and in the nodes capabilities we can indicate that this node is already predeployed? So we will have the same differentiation but only 1 state that represents that the node is ready to be picked by the scheduler. It sounds like it\u0027s more simple to represent it this way.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":121,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":122,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":123,"context_line":"  can also be enqueued on the node from this state."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"DEPLOYING"},{"line_number":126,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_ef88e272","line":123,"in_reply_to":"5a890539_d73b2a9a","updated":"2014-11-17 18:08:46.000000000","message":"Maybe.  My use case doesn\u0027t involve Nova at all -- it looks like the best course of action here would be to let those whose uses cases involve Nova give be the verbiage they want.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":138,"context_line":"DEPLOYFAIL"},{"line_number":139,"context_line":"  If deploying a node fails for some reason, Ironic will transition the"},{"line_number":140,"context_line":"  node to DEPLOYFAIL, and operator intervention will be required to"},{"line_number":141,"context_line":"  resolve the situation."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"DEPLOYED"},{"line_number":144,"context_line":"  Nodes in DEPLOYED are ready to be handed over to a workload.  Ironic"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_890fd52d","line":141,"updated":"2014-11-12 22:49:20.000000000","message":"ditto prebootfail - there are also transient issues that can be recovered from. I\u0027m not sure we have a great answer yet, but it\u0027s worth noodling on and at least mentioning in the spec if we choose not to address it.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":138,"context_line":"DEPLOYFAIL"},{"line_number":139,"context_line":"  If deploying a node fails for some reason, Ironic will transition the"},{"line_number":140,"context_line":"  node to DEPLOYFAIL, and operator intervention will be required to"},{"line_number":141,"context_line":"  resolve the situation."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"DEPLOYED"},{"line_number":144,"context_line":"  Nodes in DEPLOYED are ready to be handed over to a workload.  Ironic"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_af8a5a61","line":141,"in_reply_to":"5a890539_890fd52d","updated":"2014-11-17 18:08:46.000000000","message":"Ditto my response. :)","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":200,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":201,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":202,"context_line":"-- at the summt we talked in terms of a wait flag, but that area still"},{"line_number":203,"context_line":"needs to be hashed out."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"Alternatives"},{"line_number":206,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_a91e5161","line":203,"updated":"2014-11-12 22:49:20.000000000","message":"A list of states for which the \"wait flag\" is valid would be good to put here.\n\nIIRC, it is: discovering, deploying, deleting, zapping","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":200,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":201,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":202,"context_line":"-- at the summt we talked in terms of a wait flag, but that area still"},{"line_number":203,"context_line":"needs to be hashed out."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"Alternatives"},{"line_number":206,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_efd6224e","line":203,"in_reply_to":"5a890539_a91e5161","updated":"2014-11-17 18:08:46.000000000","message":"I was thinking more about hashing out the logic around using the wait flag -- the conversations at the summit were a bit handwavy.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"8f392089c40e61cacc79ba8ba94dc14ec95d0210","unresolved":false,"context_lines":[{"line_number":230,"context_line":"Nova driver impact"},{"line_number":231,"context_line":"------------------"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"NOSTATE has been renamed to AVAILABE."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"Security impact"},{"line_number":236,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_3721ce4d","line":233,"updated":"2014-11-13 11:49:24.000000000","message":"and PREBOOT according to the way the spec is written (But see the comment on L123)","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":230,"context_line":"Nova driver impact"},{"line_number":231,"context_line":"------------------"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"NOSTATE has been renamed to AVAILABE."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"Security impact"},{"line_number":236,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_afb89a11","line":233,"in_reply_to":"5a890539_3721ce4d","updated":"2014-11-17 18:08:46.000000000","message":"Right, but we need to get that hashed out.","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"2c9cc76a572efd703792034d4b372dd065cff11f","unresolved":false,"context_lines":[{"line_number":303,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":304,"context_line":""},{"line_number":305,"context_line":"Anyone have a link to some developer session notes?  I was sorta busy"},{"line_number":306,"context_line":"being a whiteboard monkey."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_c919dd7a","line":306,"updated":"2014-11-12 22:49:20.000000000","message":"I think we all were ... most of this was hashed out during the friday meetup, and I don\u0027t recall anyone taking notes (though about a dozen people took pictures of the whiteboard when we were done!).","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"a08b78274a5d19804cd879295895ee6bf288295b","unresolved":false,"context_lines":[{"line_number":303,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":304,"context_line":""},{"line_number":305,"context_line":"Anyone have a link to some developer session notes?  I was sorta busy"},{"line_number":306,"context_line":"being a whiteboard monkey."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a890539_6f495230","line":306,"in_reply_to":"5a890539_c919dd7a","updated":"2014-11-17 18:08:46.000000000","message":"Right, but throwing \"You had to have been there\" into the spec would just be taunting everyone. :)","commit_id":"0d0fff9b20007d27448ff360b119aae6fb145499"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* We also need a state to put nodes in when they are performing configuration"},{"line_number":31,"context_line":"  tasks that can reasonably be expected to take hours to complete, such as RAID"},{"line_number":32,"context_line":"  configuration and burnin.  It is unreasonable to force upstream consumers of"},{"line_number":33,"context_line":"  Ironic managed nodes to wait hours between the time they request a node and"},{"line_number":34,"context_line":"  get it, so running these tasks as part of DEPLOYING or DEPLOYWAIT is"},{"line_number":35,"context_line":"  nonviable."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_1546a14f","line":32,"updated":"2014-11-20 19:26:14.000000000","message":"burnin?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0d2554ec55a4f4ce9539b74042a50fb40accf9d2","unresolved":false,"context_lines":[{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* We also need a state to put nodes in when they are performing configuration"},{"line_number":31,"context_line":"  tasks that can reasonably be expected to take hours to complete, such as RAID"},{"line_number":32,"context_line":"  configuration and burnin.  It is unreasonable to force upstream consumers of"},{"line_number":33,"context_line":"  Ironic managed nodes to wait hours between the time they request a node and"},{"line_number":34,"context_line":"  get it, so running these tasks as part of DEPLOYING or DEPLOYWAIT is"},{"line_number":35,"context_line":"  nonviable."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_46ab061e","line":32,"in_reply_to":"5a890539_1546a14f","updated":"2014-11-21 11:36:33.000000000","message":"Yes burnin/burn-in/system stress. Is a type of test","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":37,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":38,"context_line":"  decomissioning blueprints handle this add DECOMMISSIONING and"},{"line_number":39,"context_line":"  DECOMMISSIONED states, but it would also be useful to perform"},{"line_number":40,"context_line":"  decomissioning tasks on freshly-added nodes."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* We also need to let external orchestration systems hook into parts of the"},{"line_number":43,"context_line":"  state machine for each node to let them manage parts of the node lifecycle"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_a6150541","line":40,"updated":"2014-11-18 14:57:19.000000000","message":"Can we lowercase \"DECOMMISSIONING\" and \"DECOMMISSIONED\" to be clear that they are not states in the new state machine?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":37,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":38,"context_line":"  decomissioning blueprints handle this add DECOMMISSIONING and"},{"line_number":39,"context_line":"  DECOMMISSIONED states, but it would also be useful to perform"},{"line_number":40,"context_line":"  decomissioning tasks on freshly-added nodes."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* We also need to let external orchestration systems hook into parts of the"},{"line_number":43,"context_line":"  state machine for each node to let them manage parts of the node lifecycle"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_8a2c084c","line":40,"in_reply_to":"5a890539_a6150541","updated":"2014-11-21 16:09:26.000000000","message":"Ya, will do for v4.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":49,"context_line":"We will rewrite the Ironic state machine to include the following states:"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"ENROLL"},{"line_number":52,"context_line":"  This is the state that all nodes start off in. When a node is in ENROLL,"},{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_d5d7b94d","line":52,"updated":"2014-11-20 19:26:14.000000000","message":"That means the state ENROLL shall be set by node-create? which is used to register the node. Are you proposing this by ENROLL? Or the state ENROLL is set after node is registered but before discovery?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":49,"context_line":"We will rewrite the Ironic state machine to include the following states:"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"ENROLL"},{"line_number":52,"context_line":"  This is the state that all nodes start off in. When a node is in ENROLL,"},{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_caab7087","line":52,"in_reply_to":"5a890539_9167eab6","updated":"2014-11-21 16:09:26.000000000","message":"Yes -- the intent is that all freshly-created nodes start in ENROLL, and they stay there just long enough to run through discovery (if that path is being used), or for Ironic to verify that it can manage the node with the driver and creds that were provided -- once that happens, it should go to INIT.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0d2554ec55a4f4ce9539b74042a50fb40accf9d2","unresolved":false,"context_lines":[{"line_number":49,"context_line":"We will rewrite the Ironic state machine to include the following states:"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"ENROLL"},{"line_number":52,"context_line":"  This is the state that all nodes start off in. When a node is in ENROLL,"},{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_9167eab6","line":52,"in_reply_to":"5a890539_d5d7b94d","updated":"2014-11-21 11:36:33.000000000","message":"AFAIUI once u register a node in Ironic it goes to ENROLL from there u can trigger the discover and after discovered it goes to INIT","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":52,"context_line":"  This is the state that all nodes start off in. When a node is in ENROLL,"},{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"},{"line_number":56,"context_line":"  being booted into a discovery image, otherwise it should transition"},{"line_number":57,"context_line":"  to INIT."},{"line_number":58,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_553ae998","line":55,"updated":"2014-11-20 19:26:14.000000000","message":"Means the Discovery shall set the state from Enroll to DISCOVERING?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":52,"context_line":"  This is the state that all nodes start off in. When a node is in ENROLL,"},{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"},{"line_number":56,"context_line":"  being booted into a discovery image, otherwise it should transition"},{"line_number":57,"context_line":"  to INIT."},{"line_number":58,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_2a9eb454","line":55,"in_reply_to":"5a890539_553ae998","updated":"2014-11-21 16:09:26.000000000","message":"More or less.  The mental model I had in mind when thinking about this part of the state machine has already been discredited, so we probably should rethink the whole ENROLL -\u003e DISCOVERING -\u003e INIT transition sequence.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"},{"line_number":56,"context_line":"  being booted into a discovery image, otherwise it should transition"},{"line_number":57,"context_line":"  to INIT."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"DISCOVERING"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_750fe5e1","line":56,"updated":"2014-11-20 19:26:14.000000000","message":"Who else can set the provision state to INIT if not Discovery?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0d2554ec55a4f4ce9539b74042a50fb40accf9d2","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"},{"line_number":56,"context_line":"  being booted into a discovery image, otherwise it should transition"},{"line_number":57,"context_line":"  to INIT."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"DISCOVERING"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_e63b12e9","line":56,"in_reply_to":"5a890539_750fe5e1","updated":"2014-11-21 11:36:33.000000000","message":"Operators by manually transitioning from ENROLL to INIT (that\u0027s why I think it\u0027s a bit redundant, cause they have to do the same from INIT to AVAIABLE)","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  From ENROLL, the only allowed"},{"line_number":55,"context_line":"  provisioner state transitions are to DISCOVERING if the node is"},{"line_number":56,"context_line":"  being booted into a discovery image, otherwise it should transition"},{"line_number":57,"context_line":"  to INIT."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"DISCOVERING"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_eab90c7a","line":56,"in_reply_to":"5a890539_e63b12e9","updated":"2014-11-21 16:09:26.000000000","message":"Yeah, the model I had in mind when writing this up is not the one y\u0027all want to actually use, so a different state transition path is called for.\n\nThe one that springs to mind is:\nNode create via API -\u003e ENROLL\n\nIronic verifies that it can manage the node with the driver and credentials passed at node create time.  If it can, node goes to INIT.  If it cannot, node goes to ENROLLFAIL\n\nIf the site wants to use a discovery image to flesh out the details of what the node has, an operator (or a system acting on their behalf) can pick an appropriate ramdisk image from Glance (or wherever), transition the node to DISCOVERING, and boot to the ramdisk.  If that fails, go to DISCOVERFAIL, otherwise the ramdisk will do what it will do and transition back to INIT when finished.\n\nThoughts?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"1cc26986a6d29354e7da360dc8e29295e5fe5ec2","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_b6a473ba","line":67,"updated":"2014-11-17 21:07:06.000000000","message":"Discovery can be done out-of-band as well.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d37513352ab868e9b920ac7a7bff611a059868c9","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_c825770b","line":67,"updated":"2014-11-20 06:58:11.000000000","message":"Wan-yen raises a valid point here, and I agree with Jim\u0027s suggestion.\n\nI can imagine the process for an out-of-band discovery being something like this:\n- operator registers a node (therefor node is in ENROLL state)\n- operator sets \"discover\" flag (that could have been passed via \"node create\" or separately)\n- node transitions to DISCOVERING, driver peforms out-of-band operations\n- upon completion, node transitions to INIT\n- or upon failure, to DISCOVERYFAIL\n\nSo, yea, I would either remove in-band specific wording OR add wording to cover the out-of-band flow as well.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_384af255","line":67,"in_reply_to":"5a890539_13529d34","updated":"2014-11-19 10:12:12.000000000","message":"+ \"If discovery failed for any reason, it should transition to DISCOVERYFAIL.\"\n\n2. I think on Nisha\u0027s patch [1] some folks votes for discovery to overwrite things. I don\u0027t support it, just FYI.\n\nhttps://review.openstack.org/#/c/100951/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_d567b94f","line":67,"in_reply_to":"5a890539_384af255","updated":"2014-11-20 19:26:14.000000000","message":"If the operator has tried to resolve the hardware failure/issue due to which discovery failed for some attributes, cant operator re-try disocvery via discovery APIs.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_13529d34","line":67,"in_reply_to":"5a890539_8a43b56a","updated":"2014-11-18 14:57:19.000000000","message":"I think I\u0027d rather cut out words. For the purpose of this spec, how discovery is done does not matter, and how a discovery ramdisk works does not matter. \n\nMaybe \"When a node... to DISCOVERING. It is expected that the discovery process will populate some basic info about the node. The discovery process must be idempotent and non-destructive.\" Done.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"c824c8e39420e786ebc97c3ebe4ecfb64e4124b8","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_8a43b56a","line":67,"in_reply_to":"5a890539_b6a473ba","updated":"2014-11-18 11:40:15.000000000","message":"I think we are counting on it, but indeed the text could be improved to mention that","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c261ff5cbb92d65f40da79b60d70ab2a8489205e","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_c980a7c1","line":67,"in_reply_to":"5a890539_c825770b","updated":"2014-11-24 21:03:50.000000000","message":"I am going to simplify this by assuming that DISCOVERING always happens from INIT in the next revision.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  nondestructive to prevent Ironic from accidentaly blowing away a"},{"line_number":65,"context_line":"  node that it should not manage, but that got discovered by"},{"line_number":66,"context_line":"  mistake. If the node fails to boot to the discovery image, it should"},{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_9538d13e","line":67,"in_reply_to":"5a890539_c825770b","updated":"2014-11-20 19:26:14.000000000","message":"agree with deva. \n@Deva one question:\n- operator sets \"discover\" flag (that could have been passed via \"node create\" or separately). \nSo discovery needs to take care of this? or who take care of it?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d37513352ab868e9b920ac7a7bff611a059868c9","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"},{"line_number":71,"context_line":"  will transition the node to DISCOVERYFAIL, and operator intervention"},{"line_number":72,"context_line":"  will be required to resolve the situation."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_e82073fa","line":70,"updated":"2014-11-20 06:58:11.000000000","message":"As above, this shouldn\u0027t be specific to in-band means... so I suggest s/booting to a discovery image/the discovery attempt/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"},{"line_number":71,"context_line":"  will transition the node to DISCOVERYFAIL, and operator intervention"},{"line_number":72,"context_line":"  will be required to resolve the situation."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"INIT"},{"line_number":75,"context_line":"  Once a node has an initial set of drivers and enough configuration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_35047d7d","line":72,"updated":"2014-11-20 19:26:14.000000000","message":"If the operator has tried to resolve the hardware failure/issue due to which discovery failed for some attributes, cant operator re-try disocvery via discovery APIs.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":69,"context_line":"DISCOVERYFAIL"},{"line_number":70,"context_line":"  If booting to a discovery image a node fails for some reason, Ironic"},{"line_number":71,"context_line":"  will transition the node to DISCOVERYFAIL, and operator intervention"},{"line_number":72,"context_line":"  will be required to resolve the situation."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"INIT"},{"line_number":75,"context_line":"  Once a node has an initial set of drivers and enough configuration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_0a0c9841","line":72,"in_reply_to":"5a890539_35047d7d","updated":"2014-11-21 16:09:26.000000000","message":"Yes,  This spec says nothing about what the operator (or something acting on their behalf) does to resolve the situation.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d37513352ab868e9b920ac7a7bff611a059868c9","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_08205ff6","line":81,"updated":"2014-11-20 06:58:11.000000000","message":"I believe INIT and ENROLL have an important distinction -- ENROLL indicates merely that Ironic knows \"there is a node\" but is not yet able to manage the node - perhaps because it doesn\u0027t know what driver to use! Ironic needs more information to go from ENROLL to INIT. It might discover that itself, or be waiting for the operator to provide it.\n\n@Lucas, as to your comments:\n- there was some talk of addressing the explosion of driver combinations by allowing run-time compositing of interfaces. obviously we\u0027re not there today...\n- there was also some talk of enrolling a node with only basic IPMI credentials, and allowing the discovery phase to figure out if a more advanced driver is better(eg, if we can determine that the iLO driver works, switch to that to get more advanced functionality). this would be easier once we abstract the common mgmt parameters (address, user, password)\n- going a step further, we could potentially accept simply the IP address of a node\u0027s BMC, and try to figure out the rest by using well-known default user/passwords, for example.\n\nAll of that could happen within the state ENROLL, and not during INIT\n\nI think a separation which clearly indicates whether or not this node is capable of being managed yet is good. Ideally, ENROLL is a short-lived state, but I\u0027m still of the mind that this is separate from INIT.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"c824c8e39420e786ebc97c3ebe4ecfb64e4124b8","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_0d6b5f85","line":81,"updated":"2014-11-18 11:40:15.000000000","message":"I was thinking here, I don\u0027t see much difference between INIT and ENROLL. Perhaps we could simplify the machine state by having only INIT?\n\nWhen I read \"Once a node has an initial set of drivers\" that sounds wrong for me. First Nodes only have 1 driver. Second when enrolling a node it\u0027s already required to give it the driver, it\u0027s mandatory.\n\nBoth ENROLL and INIT requires an outside action to transition from it.\n\nLet\u0027s say we start in INIT and in order to transition from INIT to AVAILABLE it requires a API call and it should pass validations (we have validations on interfaces to verify if all the information have been supplied to Ironic be able to manage the node).\n\nIn the case of discover, a node starting in INIT would get an API call to go discover, so it goes INIT-\u003eDISCOVERING-\u003eINIT in case of success; Or INIT-\u003eDISCOVERING-\u003eDISCOVERFAIL in case of failure (from DISCOVERFAIL we can put it back to INIT or try DISCOVERING again).\n\nThe thing it\u0027s simplify is that the INIT is where all the incomplete nodes are registered and the information about it could either be manually updated or discovered automatically.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"2f367a6cd245e0e7c1d323f97d3c810c0de8c9cf","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_4efeeaaf","line":81,"in_reply_to":"5a890539_08205ff6","updated":"2014-11-20 11:14:25.000000000","message":"Thanks Deva for the input.\n\nMaybe I\u0027m not thinking about the long long term. It\u0027s maybe because I don\u0027t foresee discovery to ever to find out which driver it should use. The way I see it is that operators should always be the ones selecting which driver to use, choosing a driver is more than being able to power on/off a node, it also says which deploy method it should use, what are the management capabilities exposed by that driver etc...\n\nI think it would be really hard to figure out it automatically, if there\u0027re 3 drivers able to manage that Node, which one to pick? The one that has more capabilities (assuming we are now exposing the capabilities)? What if the operator only wants to use a simple driver?\n\nWhat about credentials, if the node doesn\u0027t have a driver operator probably have to enroll it with various credentials so node can talk to different BMCs to figure out which one it can talk to.\n\nPlus, now with the ZAPPING state. IIRC It\u0027s require operators to really know the hardware they own to do the ZAPPING, and drivers are the ones describing what are the ZAPPING steps, so I believe that operators will choose the driver by themselves and not relying on a automatic mechanism to figure that out because things can go bad.\n\nAFAIUI the difference between ENROLL and INIT seems to boil down to whether the Node already has a driver or not, the problem is that I don\u0027t believe that nodes should ever be registered without a driver, it seems like a valid attribute to be mandatory.\n\nOn the 3 bullet points, 1) and 2) I don\u0027t consider valid due the assumptions above.\n\n3) is what I consider the discover, assuming the node already has a driver and valid credentials (or fallback to a default user/password) Ironic can go and figure out the rest, and I think that the INIT state makes sense for that.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_989f66b4","line":81,"in_reply_to":"5a890539_0d6b5f85","updated":"2014-11-19 10:12:12.000000000","message":"+1","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_33bf9962","line":81,"in_reply_to":"5a890539_0d6b5f85","updated":"2014-11-18 14:57:19.000000000","message":"I agree with this, I think ENROLL is pretty redundant.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_50bd97d6","line":81,"in_reply_to":"5a890539_4efeeaaf","updated":"2014-11-20 19:26:14.000000000","message":"Lucas i think i tend to agree with you :) but i think ENROLL shall be there as a new state. Reason:\nConsider following:\n\n1. ENROLL is valid state. Then at discovery provision_state looks like:\n     ENROLL --\u003e DISCOEVRING --\u003eINIT.\nor\n     ENROLL --\u003e DISCOVERING --\u003e DISCOVERYFAIL\n\n2. ENROLL is not valid state, then at discovery provision state looks like:\n\n     INIT  ---\u003e DISCOVERING  ---\u003e INIT.\n\nThe above will be confusing for operators as well as ironic to make out whether INIT was before discovery or it is after discovery.\n\nHowever, we can try to make INIT as the target_provison_state at the time of creating/registering the node but then what shall be the provision state at that time? It cannot be DISCOVERING, hence i think we need a seperate state as ENROLL","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0d2554ec55a4f4ce9539b74042a50fb40accf9d2","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_f1410e0c","line":81,"in_reply_to":"5a890539_50bd97d6","updated":"2014-11-21 11:36:33.000000000","message":"Right, the thing about ENROLL being before discover and INIT after is not necessary true, see the diagram [1]. Discover can be started from ENROLL or from INIT in the proposed flow, so IMO it\u0027s even more confusing.\n\nThe thing is, AFAIUI, both ENROLL and INIT means the same, it means that the node is registered in Ironic but may not contain all the information to be managed by it yet.\n\nWe could have a DISCOVERDONE (or DISCOVERED) state to be a valid **target state** only, akin to what the DEPLOYDONE state is:\n\nWhen you\u0027re deploying a node Ironic set the target_provision_state to DEPLOYDONE, and provision_state to DEPLOYING. Once the deployment is completed the provision_state goes to ACTIVE and target_provision_state is set to None.\n\nThe discover could do it as well, starting with provision_state INIT and triggering the discover the target_provision_state can be set to DISCOVERDONE and provision_state to DISCOVERING, after it\u0027s done provision_state is set back to INIT and targer_provision_state is None.\n\n[1] https://i.imgur.com/tCxUCYk.jpg","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":79,"context_line":"  by itself.  In the INIT state, an API caller can either transition"},{"line_number":80,"context_line":"  the node to AVAILABLE, or queue up destructive and/or long-running"},{"line_number":81,"context_line":"  tasks and then transition the node to ZAPPING."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"ZAPPING"},{"line_number":84,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_45e5b3a6","line":81,"in_reply_to":"5a890539_f1410e0c","updated":"2014-11-21 16:09:26.000000000","message":"What I had in mind:\n\nENROLL: Ironic knows a node exists, but has not verified that it can manage it.\n\nINIT: Ironic has verified that it can manage the node, but the node may require further configuration before it can be made available.\n\nThe reason I make that distinction is that in Crowbar, our default node discovery process looks like this:\n\n1. System PXE boots.  The provisioner does not have a custom config for the node (based on MAC address and IP address), so it gets a node discovery image.\n\n2. After the usual boot stuff, the discovery image calls the node create API, handing over the MAC addresses of the node.  Crowbar allocates a static IPv4 and IPv6 address for the node, has the provisioner create custom pxelinux and elilo boot records for the node, creates DNS entries for the node.  At this point, the node would be in ENROLL from Ironic\u0027s point of view.\n\n3: Crowbar then binds a set of discovery roles to the node, and executes those roles (as a combination of shell scripts and chef-client runs).  Based on what those roles discover, Crowbar composes a driver set for the node that lets it manage the node (including power states via ipmi or idrac).  Once that is finished, the node would be in INIT from Ironic\u0027s point of view.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d37513352ab868e9b920ac7a7bff611a059868c9","unresolved":false,"context_lines":[{"line_number":87,"context_line":"  * changing RAID levels,"},{"line_number":88,"context_line":"  * updating firmware,"},{"line_number":89,"context_line":"  * going through burnin."},{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_281b5bcb","line":90,"updated":"2014-11-20 06:58:11.000000000","message":"Enqueued how and where? It\u0027s worth describing the mechanism of said enqueuing and dequeuing somehwere in this spec.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":87,"context_line":"  * changing RAID levels,"},{"line_number":88,"context_line":"  * updating firmware,"},{"line_number":89,"context_line":"  * going through burnin."},{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_45585356","line":90,"in_reply_to":"5a890539_281b5bcb","updated":"2014-11-21 16:09:26.000000000","message":"I left that bit vague because I do not know what mechanisms along those lines Ironic already offers, and would rather not invent one when I can just steal one.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c261ff5cbb92d65f40da79b60d70ab2a8489205e","unresolved":false,"context_lines":[{"line_number":87,"context_line":"  * changing RAID levels,"},{"line_number":88,"context_line":"  * updating firmware,"},{"line_number":89,"context_line":"  * going through burnin."},{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_697b33be","line":90,"in_reply_to":"5a890539_3500a633","updated":"2014-11-24 21:03:50.000000000","message":"Is the same mechanism used for DEPLOYING tasks?  If not, should it be?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"9326122453b164af8178b0e54c5bb60ade880d65","unresolved":false,"context_lines":[{"line_number":87,"context_line":"  * changing RAID levels,"},{"line_number":88,"context_line":"  * updating firmware,"},{"line_number":89,"context_line":"  * going through burnin."},{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_3500a633","line":90,"in_reply_to":"5a890539_45585356","updated":"2014-11-24 17:47:17.000000000","message":"As it stands, each driver exposes a list of ZAPPING tasks/steps with a priority, and when it gets to ZAPPING, the conductor executes them in that order.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":94,"context_line":"  ZAPPING is also where we expect to perform DECOMMISSIONING tasks."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"ZAPFAIL"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_30956be4","line":93,"updated":"2014-11-20 19:26:14.000000000","message":"If it is applicable for multiple tasks at a time, that said the state remains ZAPPING till all the tasks are completed, then it cant set ZAPFAIL for any one of the task(s) failed. It may be difficult for operator to know\u0027figure out which task has failed under ZAPPING tasks.\n\nWhen we say the tasks for ZAPPING shall be enqueued during either INIT state or DELETED state, then when once ZAPFAIL has happened, then who sets it back to ENROLL state again for completeing task.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  Tasks for ZAPPING should have been enqueued during either the INIT"},{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":94,"context_line":"  ZAPPING is also where we expect to perform DECOMMISSIONING tasks."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"ZAPFAIL"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_45069321","line":93,"in_reply_to":"5a890539_30956be4","updated":"2014-11-21 16:09:26.000000000","message":"If we expose tasks as a list, it is trivial to also expose which tasks passed/failed/were not run.  ZAPFAIL is a node state, not a result from any particular task.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":94,"context_line":"  ZAPPING is also where we expect to perform DECOMMISSIONING tasks."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"ZAPFAIL"},{"line_number":97,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_f3043119","line":94,"updated":"2014-11-18 14:57:19.000000000","message":"Can we lowercase \"DECOMMISSIONING\" to be clear that it\u0027s not a state in the new state machine?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":92,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":93,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":94,"context_line":"  ZAPPING is also where we expect to perform DECOMMISSIONING tasks."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"ZAPFAIL"},{"line_number":97,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_bd058f12","line":94,"in_reply_to":"5a890539_f3043119","updated":"2014-11-21 16:09:26.000000000","message":"Yes","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"c824c8e39420e786ebc97c3ebe4ecfb64e4124b8","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  to make node config changes), or DEPLOYING (if all your changes can be made"},{"line_number":106,"context_line":"  out of band).  In the AVAILABLE state, short-lived and"},{"line_number":107,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":108,"context_line":"  transitions to DEPLOYING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"PREBOOTING"},{"line_number":111,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_ad5c0b7e","line":108,"updated":"2014-11-18 11:40:15.000000000","message":"Another thing that makes me think here is that from AVAILABLE a node should be able to go back to INIT, for example if the operator wants to to change the driver of that node. That would require a new set of information to be passed to the node, and it would require validations to be able to transition from INIT to AVAILABLE again.\n\nOR\n\nWe can tell the operator to delete the node and recreate it, but sounds too aggressive.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  to make node config changes), or DEPLOYING (if all your changes can be made"},{"line_number":106,"context_line":"  out of band).  In the AVAILABLE state, short-lived and"},{"line_number":107,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":108,"context_line":"  transitions to DEPLOYING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"PREBOOTING"},{"line_number":111,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_dd541b00","line":108,"in_reply_to":"5a890539_70445374","updated":"2014-11-21 16:09:26.000000000","message":"Stupid oversight on my part.  I will add that back.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"c683a0972c88e61440c479f7f06e24db352f4348","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  to make node config changes), or DEPLOYING (if all your changes can be made"},{"line_number":106,"context_line":"  out of band).  In the AVAILABLE state, short-lived and"},{"line_number":107,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":108,"context_line":"  transitions to DEPLOYING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"PREBOOTING"},{"line_number":111,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_70445374","line":108,"in_reply_to":"5a890539_86cc89bc","updated":"2014-11-20 19:26:14.000000000","message":"+1","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  to make node config changes), or DEPLOYING (if all your changes can be made"},{"line_number":106,"context_line":"  out of band).  In the AVAILABLE state, short-lived and"},{"line_number":107,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":108,"context_line":"  transitions to DEPLOYING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"PREBOOTING"},{"line_number":111,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_86cc89bc","line":108,"in_reply_to":"5a890539_ad5c0b7e","updated":"2014-11-18 14:57:19.000000000","message":"I agree with Lucas, we even called that out during the summit: https://i.imgur.com/tCxUCYk.jpg\n\n\"tasks can be queued up to be handled when the node transitions to deploying\" - not sure I like this wording, makes it sound like Ironic can accept arbitrary tasks to be done during the deploy; this should be handled by the driver, capabilities, flavors, etc, and sent with the \"deploy\" API call.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":114,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":115,"context_line":"  if the node does not transition to PREBOOT within a specified amount"},{"line_number":116,"context_line":"  of time."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOTFAIL"},{"line_number":119,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_e66aad7f","line":116,"updated":"2014-11-18 14:57:19.000000000","message":"We didn\u0027t call these states out during the summit session. I like that we have PREBOOTFAIL, however the diagram we made specifies that PREBOOTING should transition back to AVAILABLE once it is ready for deploy.\n\nI\u0027m okay with being told I\u0027m wrong here, just seems a bit redundant to me.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"9ea49aafaec150f0c846aec35df2c25c640290dd","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":114,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":115,"context_line":"  if the node does not transition to PREBOOT within a specified amount"},{"line_number":116,"context_line":"  of time."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOTFAIL"},{"line_number":119,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_e9f0be92","line":116,"in_reply_to":"5a890539_09c26a52","updated":"2014-11-18 15:06:48.000000000","message":"s/PREDEPLOYING/PREBOOTING","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"01245b85f1990903c710bd373cba46623f0db779","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":114,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":115,"context_line":"  if the node does not transition to PREBOOT within a specified amount"},{"line_number":116,"context_line":"  of time."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOTFAIL"},{"line_number":119,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_09c26a52","line":116,"in_reply_to":"5a890539_e66aad7f","updated":"2014-11-18 15:06:01.000000000","message":"+1, I will C\u0026P my comment from the patch-set #2:\n\n\"I think I understand the difference trying to be represented here, where PREBOOT would be for a quicker deployment and AVAILABLE may take more time. But wouldn\u0027t it be more sane if after PREDEPLOYING the node is put back to AVAILABLE state and in the nodes capabilities we can indicate that this node is already predeployed? So we will have the same differentiation but only 1 state that represents that the node is ready to be picked by the scheduler. It sounds like it\u0027s more simple to represent it this way.\"","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c261ff5cbb92d65f40da79b60d70ab2a8489205e","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":114,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":115,"context_line":"  if the node does not transition to PREBOOT within a specified amount"},{"line_number":116,"context_line":"  of time."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"PREBOOTFAIL"},{"line_number":119,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_04de166d","line":116,"in_reply_to":"5a890539_e66aad7f","updated":"2014-11-24 21:03:50.000000000","message":"I think we need someone whose desired workflow involves booting into a ramdisk as part of deploying a node.  IPA guys, chime in here and explain how y\u0027all want this part of the state machine to work.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":125,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":126,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":127,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":128,"context_line":"  can also be enqueued on the node from this state."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"DEPLOYING"},{"line_number":131,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_46d9c155","line":128,"updated":"2014-11-18 14:57:19.000000000","message":"See above comments about PREBOOT and \"queueing tasks\".","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c261ff5cbb92d65f40da79b60d70ab2a8489205e","unresolved":false,"context_lines":[{"line_number":125,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":126,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":127,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":128,"context_line":"  can also be enqueued on the node from this state."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"DEPLOYING"},{"line_number":131,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_644fda34","line":128,"in_reply_to":"5a890539_46d9c155","updated":"2014-11-24 21:03:50.000000000","message":"If we can agree that for now the drivers are the only ones that can offer tasks to run during ZAPPING and DEPLOYING, I will change the queuing language to reflect that -- I just have a nagging concern that model will wind up being too restrictive until we either get composable drivers or the ability to bind multiple driversets onto a node.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":136,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":137,"context_line":"    that may be required by additional subsystems."},{"line_number":138,"context_line":"  Tasks for DEPLOYING should have been enqueued during either"},{"line_number":139,"context_line":"  AVAILABLE or PREBOOT, and the failure of any task will cause the"},{"line_number":140,"context_line":"  node to transition to DEPLOYFAIL. Once all the tasks are finished,"},{"line_number":141,"context_line":"  Ironic should transition the node to DEPLOYED."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_26bf5562","line":138,"updated":"2014-11-18 14:57:19.000000000","message":"Again, this queueing thing seems off to me.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":136,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":137,"context_line":"    that may be required by additional subsystems."},{"line_number":138,"context_line":"  Tasks for DEPLOYING should have been enqueued during either"},{"line_number":139,"context_line":"  AVAILABLE or PREBOOT, and the failure of any task will cause the"},{"line_number":140,"context_line":"  node to transition to DEPLOYFAIL. Once all the tasks are finished,"},{"line_number":141,"context_line":"  Ironic should transition the node to DEPLOYED."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_bdd66f4d","line":138,"in_reply_to":"5a890539_26bf5562","updated":"2014-11-21 16:09:26.000000000","message":"well, what would you recommend for tracking what Ironic should do to a node in any given state?","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":177,"context_line":""},{"line_number":178,"context_line":"DELETED"},{"line_number":179,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":180,"context_line":"  scrubbed or had certian persistent configuration (such as RAID"},{"line_number":181,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":182,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":183,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_663a3de8","line":180,"updated":"2014-11-18 14:57:19.000000000","message":"Nit: s/certian/certain/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":177,"context_line":""},{"line_number":178,"context_line":"DELETED"},{"line_number":179,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":180,"context_line":"  scrubbed or had certian persistent configuration (such as RAID"},{"line_number":181,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":182,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":183,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_1dc5c38d","line":180,"in_reply_to":"5a890539_663a3de8","updated":"2014-11-21 16:09:26.000000000","message":"Will fix.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":199,"context_line":"           |      ^"},{"line_number":200,"context_line":"           ^      |"},{"line_number":201,"context_line":"           |      v"},{"line_number":202,"context_line":"           \\--- RESCUE"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":205,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_c9106250","line":202,"updated":"2014-11-18 14:57:19.000000000","message":"I don\u0027t see RESCUE defined above :(","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":199,"context_line":"           |      ^"},{"line_number":200,"context_line":"           ^      |"},{"line_number":201,"context_line":"           |      v"},{"line_number":202,"context_line":"           \\--- RESCUE"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":205,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_d8800e49","line":202,"in_reply_to":"5a890539_c9106250","updated":"2014-11-19 10:12:12.000000000","message":"line #158","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"1cc26986a6d29354e7da360dc8e29295e5fe5ec2","unresolved":false,"context_lines":[{"line_number":204,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":205,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":206,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":207,"context_line":"-- at the summt we talked in terms of a wait flag, but that area still"},{"line_number":208,"context_line":"needs to be hashed out."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_f60efbe3","line":207,"updated":"2014-11-17 21:07:06.000000000","message":"s/summt/summit","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":204,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":205,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":206,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":207,"context_line":"-- at the summt we talked in terms of a wait flag, but that area still"},{"line_number":208,"context_line":"needs to be hashed out."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_fd439710","line":207,"in_reply_to":"5a890539_f60efbe3","updated":"2014-11-21 16:09:26.000000000","message":"Will fix.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":235,"context_line":"Nova driver impact"},{"line_number":236,"context_line":"------------------"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"NOSTATE has been renamed to AVAILABE."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Security impact"},{"line_number":241,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_98eda628","line":238,"updated":"2014-11-19 10:12:12.000000000","message":"s/AVAILABE/AVAILABLE/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"016460052d04c77b02087cdd640183d5beca4cc3","unresolved":false,"context_lines":[{"line_number":265,"context_line":"Developer impact"},{"line_number":266,"context_line":"----------------"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"This exists to get developer feedback ind impact assesment."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"Implementation"},{"line_number":271,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_34a8c38c","line":268,"updated":"2014-11-23 15:24:23.000000000","message":"s/assesment/assessment/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":265,"context_line":"Developer impact"},{"line_number":266,"context_line":"----------------"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"This exists to get developer feedback ind impact assesment."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"Implementation"},{"line_number":271,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_1892969f","line":268,"updated":"2014-11-19 10:12:12.000000000","message":"s/ind/and/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"016460052d04c77b02087cdd640183d5beca4cc3","unresolved":false,"context_lines":[{"line_number":289,"context_line":"Testing"},{"line_number":290,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"We have alot of talking to do about this."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_e04bd684","line":292,"updated":"2014-11-23 15:24:23.000000000","message":"s/alot/a lot/","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"5f36c4499d600a45e39153d6cc7ead49e3cb8e93","unresolved":false,"context_lines":[{"line_number":295,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":296,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_58e33e33","line":298,"updated":"2014-11-19 10:12:12.000000000","message":"I think we should put here at least the most possible issues (e.g. NOSTATE vs AVAILABLE for nova driver) and ideas to solve them...","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"884bc239351705211e2bb6e08601e3221eafbf29","unresolved":false,"context_lines":[{"line_number":295,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":296,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_a9431640","line":298,"updated":"2014-11-18 14:57:19.000000000","message":"I\u0027m particularly scared about this, but not much we can do to avoid it. :(","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":295,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":296,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_7dfde7b0","line":298,"in_reply_to":"5a890539_58e33e33","updated":"2014-11-21 16:09:26.000000000","message":"Well, start getting detailed in your comments, then. I am managing this spec more as a moderator than a dictator. :)","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"4285ef8ffcdc87d71c14905e0f104ceb21dc0bc5","unresolved":false,"context_lines":[{"line_number":308,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"Anyone have a link to some developer session notes?  I was sorta busy"},{"line_number":311,"context_line":"being a whiteboard monkey."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_73aa0186","line":311,"updated":"2014-11-18 14:25:40.000000000","message":"At the very least, we could link to the whiteboard picture: https://i.imgur.com/tCxUCYk.jpg","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1b36c1fb60805097f8c460aa94ba66ea6e900083","unresolved":false,"context_lines":[{"line_number":308,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"Anyone have a link to some developer session notes?  I was sorta busy"},{"line_number":311,"context_line":"being a whiteboard monkey."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_bd32efa4","line":311,"in_reply_to":"5a890539_73aa0186","updated":"2014-11-21 16:09:26.000000000","message":"Good idear.","commit_id":"1e7ce81205bdb7aa2a83d0f8e19824e9cc361e77"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":38,"context_line":"  decomissioning blueprints handle this add decommissioning and"},{"line_number":39,"context_line":"  decomissioned states, but it would also be useful to perform"},{"line_number":40,"context_line":"  decomissioning tasks on freshly-added nodes."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* We also need to let external orchestration systems hook into parts of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_336a4c1a","line":39,"updated":"2014-11-26 02:52:07.000000000","message":"I\u0027m not quite sure how to parse this sentence. Oh, maybe \"... blueprints handle this by adding \u0027decommissioning\u0027 and \u0027decommissioned\u0027 states...\"\n\nWhich decom blueprint are you referring to? https://blueprints.launchpad.net/ironic/+spec/decom-nodes","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* We also need a place to handle node decomissioning tasks.  The current"},{"line_number":38,"context_line":"  decomissioning blueprints handle this add decommissioning and"},{"line_number":39,"context_line":"  decomissioned states, but it would also be useful to perform"},{"line_number":40,"context_line":"  decomissioning tasks on freshly-added nodes."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* We also need to let external orchestration systems hook into parts of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_359abdc5","line":39,"in_reply_to":"5a890539_336a4c1a","updated":"2014-12-01 16:30:19.000000000","message":"I am referring to https://review.openstack.org/#/c/102685/","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  Once Ironic has verified"},{"line_number":55,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_bfbcf507","line":56,"updated":"2014-11-28 08:51:52.000000000","message":"Should it be assumed that it means if only driver_info is populated in the node object, then ironic can manage the node and move it to INIT.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":54,"context_line":"  cannot take any further action by itself.  Once Ironic has verified"},{"line_number":55,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_35871d14","line":56,"in_reply_to":"5a890539_bfbcf507","updated":"2014-12-01 16:30:19.000000000","message":"No.  Ironic has to be able to verify that it can actually go out and talk to that node.  For ipmitool, this woud involve running ipmitool bmc info against the node and verifying that you get back a non-error response.  The drivers themselves can tell when they have all the required properties (although, in this case the ipmitool driver mistakenly assumes that the ipmi username and password are optional -- that should be fixed).\n\nAs far as mechanics go, the validate method in the drivers should be extended to notice when they are being called against a node in ENROLL.\n\nThe logic should look like this\n\n* Do I have all the info I need?  If not, fail the same way I currently do.\n* Is the node in ENROLL?  If not, succeed the way I currently do.\n* Can I talk to the node using the present credentials?  If so, move the node to INIT, otherwise move to ENROLLFAIL.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_3ff2c506","line":59,"updated":"2014-11-28 08:51:52.000000000","message":"But node can be created in multiple steps using node-create and node-update or in a single state node-create with different options. The node-update can be repeated any number of times before provisioning.\nSo when and how does Ironic determine that it cannot manage the node and move it to ENROLLFAIL?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_10994f79","line":59,"in_reply_to":"5a890539_3ff2c506","updated":"2014-12-01 16:30:19.000000000","message":"See above comments.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"},{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_734774a3","line":64,"updated":"2014-11-26 02:52:07.000000000","message":"Will it be put in maintenance mode?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"},{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_10706f3f","line":64,"in_reply_to":"5a890539_734774a3","updated":"2014-12-01 16:30:19.000000000","message":"Is there a good reason to do so?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"},{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_b8e9b480","line":66,"updated":"2014-11-26 02:52:07.000000000","message":"is this before and/or after INIT?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"},{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_ff359da8","line":66,"in_reply_to":"5a890539_b8e9b480","updated":"2014-11-28 08:51:52.000000000","message":"This is after ENROLL--\u003e INIT","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"},{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"},{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_13dd50e0","line":68,"updated":"2014-11-26 02:52:07.000000000","message":"extra \u0027to\u0027.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"DISCOVERING"},{"line_number":67,"context_line":"  When a node is being discovered, it should immediately transition to"},{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"},{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_90853fd1","line":68,"in_reply_to":"5a890539_13dd50e0","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"},{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"},{"line_number":72,"context_line":"  that got discovered by mistake. If discovery fails, the node will"},{"line_number":73,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_f3e9a47f","line":71,"updated":"2014-11-26 02:52:07.000000000","message":"typo \u0027accidentaly\u0027 -\u003e \u0027accidentally\u0027","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  to DISCOVERING. It is expected that the discovery process will"},{"line_number":69,"context_line":"  result in extra properties being added to the node. Any actions the"},{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"},{"line_number":72,"context_line":"  that got discovered by mistake. If discovery fails, the node will"},{"line_number":73,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_b06b1b1e","line":71,"in_reply_to":"5a890539_f3e9a47f","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"},{"line_number":72,"context_line":"  that got discovered by mistake. If discovery fails, the node will"},{"line_number":73,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"DISCOVERYFAIL"},{"line_number":76,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_13b2b093","line":73,"updated":"2014-11-26 02:52:07.000000000","message":"I\u0027d like to understand what \u0027discover\u0027 means here. Are we talking about discovering properties/characteristics of a node, or discovering nodes? If the former, I thought we wanted to use a different term like introspection, interrogation, or was it agreed to use \u0027discover\u0027?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  discovery process takes MUST be nondestructive to prevent Ironic"},{"line_number":71,"context_line":"  from accidentaly blowing away a node that it should not manage, but"},{"line_number":72,"context_line":"  that got discovered by mistake. If discovery fails, the node will"},{"line_number":73,"context_line":"  transition to DISCOVERYFAIL."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"DISCOVERYFAIL"},{"line_number":76,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_1f3b499d","line":73,"in_reply_to":"5a890539_13b2b093","updated":"2014-11-28 08:51:52.000000000","message":"It means to discover node properties i.e. introspect the hardware.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":75,"context_line":"DISCOVERYFAIL"},{"line_number":76,"context_line":"  If discovery fails for some reason, Ironic will transition the node"},{"line_number":77,"context_line":"  to DISCOVERYFAIL, and operator intervention will be required to"},{"line_number":78,"context_line":"  resolve the situation."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"INIT"},{"line_number":81,"context_line":"  Once Ironic has verified that it can manage the node using the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_d36bc8ee","line":78,"updated":"2014-11-26 02:52:07.000000000","message":"Will it be put in maintenance mode?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":75,"context_line":"DISCOVERYFAIL"},{"line_number":76,"context_line":"  If discovery fails for some reason, Ironic will transition the node"},{"line_number":77,"context_line":"  to DISCOVERYFAIL, and operator intervention will be required to"},{"line_number":78,"context_line":"  resolve the situation."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"INIT"},{"line_number":81,"context_line":"  Once Ironic has verified that it can manage the node using the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_bf0155b1","line":78,"in_reply_to":"5a890539_d36bc8ee","updated":"2014-11-28 08:51:52.000000000","message":"Should it be moved to maintenance mode?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"b5d3f5e4c6658e3ce12b1dc6a99684e617471d39","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":98,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":99,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":100,"context_line":"  ZAPPING is also where we expect to perform decomissioning tasks."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"ZAPFAIL"},{"line_number":103,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_ec6c75d2","line":100,"updated":"2014-11-25 14:40:04.000000000","message":"If we are ZAPPING for decommissioning at end-of-life will the node still transition to the AVAILABLE state?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"9f276e59b67f159c1632689aad6160bd5a3dcae7","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":98,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":99,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":100,"context_line":"  ZAPPING is also where we expect to perform decomissioning tasks."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"ZAPFAIL"},{"line_number":103,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_fc3163ed","line":100,"in_reply_to":"5a890539_053c212e","updated":"2014-11-26 11:08:08.000000000","message":"So would it be accurate to say that decommissioning for end-of-life is out of scope?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"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":"0c6574fe07bcce74e83f58b51394a8c3d0026b94","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":98,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":99,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":100,"context_line":"  ZAPPING is also where we expect to perform decomissioning tasks."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"ZAPFAIL"},{"line_number":103,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_053c212e","line":100,"in_reply_to":"5a890539_ec6c75d2","updated":"2014-11-26 01:30:15.000000000","message":"Part of the reason we renamed \"decommissioning\" to \"zapping\" was to cure this misconception. This refers to \"decomissioning\" the hardware between tenants. i.e. my customer spins up an instance, then deletes it. The steps we go through in \"ZAPPING\" (formerly decommissioning) would be everything required to wipe it clean of the previous tenant so it can be made AVAILABLE for the next tenant.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"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":"52aa28c89e7b739dbc364d1a1c339dccfd780407","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  or the DELETED states, and the failure of any task will cause the"},{"line_number":98,"context_line":"  node to transition to ZAPFAIL.  Once all tasks have completed"},{"line_number":99,"context_line":"  successfully, Ironic will transition the node to AVAILABLE."},{"line_number":100,"context_line":"  ZAPPING is also where we expect to perform decomissioning tasks."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"ZAPFAIL"},{"line_number":103,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_d958265a","line":100,"in_reply_to":"5a890539_fc3163ed","updated":"2014-11-26 20:07:10.000000000","message":"That\u0027s something that happens to a node exactly once; while I could see something like this in the future, it\u0027s currently not planned and IMO something likely more suited for a CMDB/HMDB than for Ironic.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":106,"context_line":"  node into maintenance mode."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"AVAILABLE"},{"line_number":109,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."},{"line_number":110,"context_line":"  From AVAILABLE, nodes can transition to:"},{"line_number":111,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":112,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_18c64868","line":109,"updated":"2014-11-26 02:52:07.000000000","message":"this may be a nit. I couldn\u0027t figure out from this if nodes go into AVAILABLE state and in that state they are cleaned, or whether (and I think this is what you mean) nodes should be/are clean when they go in the AVAILABLE state.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":106,"context_line":"  node into maintenance mode."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"AVAILABLE"},{"line_number":109,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."},{"line_number":110,"context_line":"  From AVAILABLE, nodes can transition to:"},{"line_number":111,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":112,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_df1541e6","line":109,"in_reply_to":"5a890539_18c64868","updated":"2014-11-28 08:51:52.000000000","message":"+1 to Ruby. I think it should be reworded to \"Nodes in the AVAILABLE state are cleaned, preconfigured and ready to be provisioned.\"","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":106,"context_line":"  node into maintenance mode."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"AVAILABLE"},{"line_number":109,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."},{"line_number":110,"context_line":"  From AVAILABLE, nodes can transition to:"},{"line_number":111,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":112,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_70d0d3c9","line":109,"in_reply_to":"5a890539_df1541e6","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"AVAILABLE"},{"line_number":109,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."},{"line_number":110,"context_line":"  From AVAILABLE, nodes can transition to:"},{"line_number":111,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":112,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"},{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_e1eac9d6","line":110,"updated":"2014-11-25 10:34:13.000000000","message":"new line required","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"AVAILABLE"},{"line_number":109,"context_line":"  Nodes in the AVAILABLE state are cleaned and ready to be provisioned."},{"line_number":110,"context_line":"  From AVAILABLE, nodes can transition to:"},{"line_number":111,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":112,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"},{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_b0d95bf6","line":110,"in_reply_to":"5a890539_e1eac9d6","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"cf0c138d2885e35193d95e765cdde804afc44688","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_d85a32f1","line":116,"updated":"2014-11-24 21:27:53.000000000","message":"This means the nodes can\u0027t be automatically ZAPPED during deleting, because it requires another API call to transition them out of INIT. Nodes should go directly from AVAILABLE to ZAPPING and DELETED to ZAPPING (which I realize makes the state machine a bit more complex)","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_a16fe190","line":116,"updated":"2014-11-25 10:34:13.000000000","message":"trailing whitespace here + new line required","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"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":"0c6574fe07bcce74e83f58b51394a8c3d0026b94","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_4542a9ab","line":116,"in_reply_to":"5a890539_035c347c","updated":"2014-11-26 01:30:15.000000000","message":"Lucas: That\u0027s certainly what he means. And I agree with him.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"02b5afccba41c5cb27ca35a154b7dc80396b8086","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_459fe565","line":116,"in_reply_to":"5a890539_035c347c","updated":"2014-11-26 23:38:54.000000000","message":"Lucas: right. Thanks.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_30300b07","line":116,"in_reply_to":"5a890539_a16fe190","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"6befae87b0f908c7d5f2a7585aa41a5e3e057d8c","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_035c347c","line":116,"in_reply_to":"5a890539_d85a32f1","updated":"2014-11-25 13:55:23.000000000","message":"@Josh you mean ZAPPING to AVAILABLE and DELETED to ZAPPING right?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":113,"context_line":"    not severely impact how long the node requestor has to wait for"},{"line_number":114,"context_line":"    the node, or"},{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_5065971b","line":116,"in_reply_to":"5a890539_d85a32f1","updated":"2014-12-01 16:30:19.000000000","message":"The ASCII art is incorrect.  The control flow should go straight from DELETED to ZAPPING or AVAILABLE, depending on site policies and/or the intended role for the system.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"PREBOOTING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_f8789c2c","line":118,"updated":"2014-11-26 02:52:07.000000000","message":"\u0027handled\u0027 -\u003e \u0027be handled\u0027","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":115,"context_line":"  * INIT if the operator needs to change the expected role of the"},{"line_number":116,"context_line":"    node or run the node through ZAPPING again. "},{"line_number":117,"context_line":"  In the AVAILABLE state, short-lived and"},{"line_number":118,"context_line":"  nondestructive tasks can be queued up to handled when the node"},{"line_number":119,"context_line":"  transitions to DEPLOYING."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"PREBOOTING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_703a93e8","line":118,"in_reply_to":"5a890539_f8789c2c","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"10d921606304ccccc25c1c122a743db0ff025e4e","unresolved":false,"context_lines":[{"line_number":119,"context_line":"  transitions to DEPLOYING."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"PREBOOTING"},{"line_number":122,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"},{"line_number":123,"context_line":"  enviromnent such as IPA or a similar (potentially long-running) ramdisk."},{"line_number":124,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":125,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_ffdbdd1e","line":122,"updated":"2014-11-28 08:51:52.000000000","message":"Does it mean there will be different deploy states for in-band and OOB?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":120,"context_line":""},{"line_number":121,"context_line":"PREBOOTING"},{"line_number":122,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"},{"line_number":123,"context_line":"  enviromnent such as IPA or a similar (potentially long-running) ramdisk."},{"line_number":124,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":125,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":126,"context_line":"  if the node does not transition to PREBOOT within a specified amount"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_386f8461","line":123,"updated":"2014-11-26 02:52:07.000000000","message":"\u0027enviromnent\u0027 -\u003e \u0027environment\u0027","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":120,"context_line":""},{"line_number":121,"context_line":"PREBOOTING"},{"line_number":122,"context_line":"  Nodes in PREBOOTING are in the process of booting into a pre-deploy"},{"line_number":123,"context_line":"  enviromnent such as IPA or a similar (potentially long-running) ramdisk."},{"line_number":124,"context_line":"  Nodes in PREBOOTING should transition to PREBOOT when they are ready to"},{"line_number":125,"context_line":"  perform useful work, and Ironic should transition the node to PREBOOTFAIL"},{"line_number":126,"context_line":"  if the node does not transition to PREBOOT within a specified amount"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_903d3fe0","line":123,"in_reply_to":"5a890539_386f8461","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":129,"context_line":"PREBOOTFAIL"},{"line_number":130,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"},{"line_number":131,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":132,"context_line":"  resolve the situation."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"PREBOOT"},{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_b8b1b4e1","line":132,"updated":"2014-11-26 02:52:07.000000000","message":"It isn\u0027t clear to me when a node goes into maintenance mode. That mode is separate from these states but they seem related.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":129,"context_line":"PREBOOTFAIL"},{"line_number":130,"context_line":"  If prebooting a node fails for some reason, Ironic will transition the"},{"line_number":131,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":132,"context_line":"  resolve the situation."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"PREBOOT"},{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_f004c319","line":132,"in_reply_to":"5a890539_b8b1b4e1","updated":"2014-12-01 16:30:19.000000000","message":"The node goes into maintenance mode whenever an operator tells it to -- my understanding is that it should be outside the state machine.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":132,"context_line":"  resolve the situation."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"PREBOOT"},{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_d855a050","line":134,"updated":"2014-11-26 02:52:07.000000000","message":"PREBOOTED?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  node to PREBOOTFAIL, and operator intervention will be required to"},{"line_number":132,"context_line":"  resolve the situation."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"PREBOOT"},{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_4b9de6ba","line":134,"in_reply_to":"5a890539_d855a050","updated":"2014-12-01 16:30:19.000000000","message":"Nah, because it is permissible for a node to hang out in PREBOOT for an extended period of time.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"6befae87b0f908c7d5f2a7585aa41a5e3e057d8c","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_4322bcb9","line":138,"updated":"2014-11-25 13:55:23.000000000","message":"This thing about PREBOOT going to DEPLOYING sounds a bit too complex to me. Why we don\u0027t have PREBOOT just like we have ZAPPING before the AVAILABLE state (and optional).\n\nE.g\n\nINIT -\u003e ZAPPING -\u003e PREBOOTING -\u003e AVAILABLE. \n\nAnd once in available we mark the node as ready to be deployed onto and visible by the nova scheduler.\n\nThis thing about going from INIT -\u003e ZAPPING -\u003e AVAILABLE -\u003e PREBOOTING -\u003e PREBOOT, sounds a bit too complicated, because the node first becomes available which means it can be deployed, then it goes to PREBOOTING which means it\u0027s doing some stuff and should not be deployed, only when it gets to PREBOOT it\u0027s available again to be deployed.\n\nWhat you think about making the PREBOOTING state to happen before AVAILABLE, it looks simpler to me because.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"5b6ba8894591f018789807090d9f77e7785fdf0a","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_6ad84953","line":138,"in_reply_to":"5a890539_251e7dbb","updated":"2014-11-26 12:32:38.000000000","message":"Hi Jay,\n\nI was thinking that as part of the PREBOOT it could mark the node as prebooted, for example by adding flag to the node capabilities that can be used at scheduler time to deploy a prebooted node","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"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":"0c6574fe07bcce74e83f58b51394a8c3d0026b94","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_251e7dbb","line":138,"in_reply_to":"5a890539_26c69e9a","updated":"2014-11-26 01:30:15.000000000","message":"The piece this is missing is indicating which nodes are prebooted. Lets say I want to preboot 20% of my instances; we\u0027ll end up with 80% of my instances in one state, and 20% in another state, but all appearing as \"AVAILABLE\".\n\nI\u0027m somewhat dubious on the idea of \"PREBOOT\" altogether, but if it remains, we should do it like Lucas is referencing, or make it a state that\u0027s \"parallel\" to AVAILABLE. i.e. AVAILABLE+ramdisk booted \u003d PREBOOT state, which nodes can be deployed from, etc.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"fb87662244b162c693fb466460dc81bea9cf101e","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_26c69e9a","line":138,"in_reply_to":"5a890539_4322bcb9","updated":"2014-11-25 13:59:08.000000000","message":"Oh, sounds nice and clean","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"02b5afccba41c5cb27ca35a154b7dc80396b8086","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_c5ff5534","line":138,"in_reply_to":"5a890539_6ad84953","updated":"2014-11-26 23:38:54.000000000","message":"I agree with INIT -\u003e ZAPPING -\u003e PREBOOTING -\u003e AVAILABLE, as long as we can go AVAILABLE -\u003e PREBOOTING -\u003e AVAILABLE via the API, so I can easily precache an image or boot an agent without going through ZAPPING again (which could take awhile). Also, making sure we only schedule from AVAILABLE should simplify the Nova logic some.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  Nodes in PREBOOT have booted into a suitable pre-deploy environment (such as"},{"line_number":136,"context_line":"  IPA) or a long-running ramdisk.  Nodes that were booted to PREBOOT for"},{"line_number":137,"context_line":"  maintenance purposes should transition back to AVAILABLE when finished,"},{"line_number":138,"context_line":"  otherwise they should transition to DEPLOYING.  Tasks for DEPLOYING"},{"line_number":139,"context_line":"  can also be enqueued on the node from this state."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"DEPLOYING"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_8bcc2ebd","line":138,"in_reply_to":"5a890539_c5ff5534","updated":"2014-12-01 16:30:19.000000000","message":"+1\n\nI will update the state machine to reflect this.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":141,"context_line":"DEPLOYING"},{"line_number":142,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."},{"line_number":143,"context_line":"  This should mainly consist of running a series of short-lived tasks,"},{"line_number":144,"context_line":"  such as:"},{"line_number":145,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":146,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":147,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_c1c6ad67","line":144,"updated":"2014-11-25 10:34:13.000000000","message":"new line required","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":141,"context_line":"DEPLOYING"},{"line_number":142,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."},{"line_number":143,"context_line":"  This should mainly consist of running a series of short-lived tasks,"},{"line_number":144,"context_line":"  such as:"},{"line_number":145,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":146,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":147,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_cbbd5605","line":144,"in_reply_to":"5a890539_c1c6ad67","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":146,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":147,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":148,"context_line":"    that may be required by additional subsystems."},{"line_number":149,"context_line":"  Tasks for DEPLOYING should have been enqueued during either"},{"line_number":150,"context_line":"  AVAILABLE or PREBOOT, and the failure of any task will cause the"},{"line_number":151,"context_line":"  node to transition to DEPLOYFAIL. Once all the tasks are finished,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_01a435b8","line":148,"updated":"2014-11-25 10:34:13.000000000","message":"ditto","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":146,"context_line":"  * Partitioning drives and laying down filesystems."},{"line_number":147,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":148,"context_line":"    that may be required by additional subsystems."},{"line_number":149,"context_line":"  Tasks for DEPLOYING should have been enqueued during either"},{"line_number":150,"context_line":"  AVAILABLE or PREBOOT, and the failure of any task will cause the"},{"line_number":151,"context_line":"  node to transition to DEPLOYFAIL. Once all the tasks are finished,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_0bb83e10","line":148,"in_reply_to":"5a890539_01a435b8","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":13362,"name":"Tan Lin","email":"lin.tan@intel.com","username":"zero"},"change_message_id":"3370b4582fb127a3e0e625bd1635c79e6c8e5df4","unresolved":false,"context_lines":[{"line_number":159,"context_line":"DEPLOYED"},{"line_number":160,"context_line":"  Nodes in DEPLOYED are ready to be handed over to a workload.  Ironic"},{"line_number":161,"context_line":"  should do so, and then transition the node to ACTIVE once the"},{"line_number":162,"context_line":"  handoff is complete."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"ACTIVE"},{"line_number":165,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_77ccdb6a","line":162,"updated":"2014-11-25 11:48:22.000000000","message":"A little confuse about how to do the transition.\nWill nodes send signal to Ironic? Or when its power state is on?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"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":"0c6574fe07bcce74e83f58b51394a8c3d0026b94","unresolved":false,"context_lines":[{"line_number":159,"context_line":"DEPLOYED"},{"line_number":160,"context_line":"  Nodes in DEPLOYED are ready to be handed over to a workload.  Ironic"},{"line_number":161,"context_line":"  should do so, and then transition the node to ACTIVE once the"},{"line_number":162,"context_line":"  handoff is complete."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"ACTIVE"},{"line_number":165,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_4519c9cf","line":162,"in_reply_to":"5a890539_77ccdb6a","updated":"2014-11-26 01:30:15.000000000","message":"These transitions already happen in the conductor; in fact it\u0027s rare you ever see a node in \"DEPLOYED\" because it\u0027s immediately sent into ACTIVE state. This is the case with many of the past-tense (*ED) states in Ironic today and proposed here.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"2c82eeb014ab17d6de517536187e53bd291bb9b1","unresolved":false,"context_lines":[{"line_number":193,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":194,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":195,"context_line":"  to scrub the system, run it through burnin again, or perform some"},{"line_number":196,"context_line":"  other long-running task)."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"In ascii art, the state machine will look like this (ignoring error"},{"line_number":199,"context_line":"states):"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_38706407","line":196,"updated":"2014-11-26 02:52:07.000000000","message":"your ascii art shows DELETED -\u003e INIT, not DELETED -\u003e AVAILABLE nor DELETED -\u003e ZAPPING.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":197,"context_line":""},{"line_number":198,"context_line":"In ascii art, the state machine will look like this (ignoring error"},{"line_number":199,"context_line":"states):"},{"line_number":200,"context_line":"::"},{"line_number":201,"context_line":"  ENROLL \u003e-+-\u003e INIT +-----\u003e------+\u003e AVAILABLE -+-\u003ePREBOOTING \\"},{"line_number":202,"context_line":"           ^        |            ^             |             v"},{"line_number":203,"context_line":"           |        |            |             |         PREBOOTED"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_a1928154","line":200,"updated":"2014-11-25 10:34:13.000000000","message":"must be:\n\n states)::\n \n    ENROLL -\u003e","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":197,"context_line":""},{"line_number":198,"context_line":"In ascii art, the state machine will look like this (ignoring error"},{"line_number":199,"context_line":"states):"},{"line_number":200,"context_line":"::"},{"line_number":201,"context_line":"  ENROLL \u003e-+-\u003e INIT +-----\u003e------+\u003e AVAILABLE -+-\u003ePREBOOTING \\"},{"line_number":202,"context_line":"           ^        |            ^             |             v"},{"line_number":203,"context_line":"           |        |            |             |         PREBOOTED"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_0b4f5e35","line":200,"in_reply_to":"5a890539_a1928154","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"5b6ba8894591f018789807090d9f77e7785fdf0a","unresolved":false,"context_lines":[{"line_number":204,"context_line":"           |        +-\u003e ZAPPING -/             |             |"},{"line_number":205,"context_line":"           |        |                          |             v"},{"line_number":206,"context_line":"           |        v                          +-------\u003e DEPLOYING"},{"line_number":207,"context_line":"           +\u003c-- DISCOVERING                    |             | "},{"line_number":208,"context_line":"           ^                                   |             v"},{"line_number":209,"context_line":"           +\u003c----------------------------------/          DEPLOYED"},{"line_number":210,"context_line":"           ^                                                 |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_9055a8fb","line":207,"updated":"2014-11-26 12:32:38.000000000","message":"This state machine is way too complex. 2 main problems:\n\n1) There are too many conditionals, look at INIT, it has 3 states that it can transition to. And when you get to AVAILABLE you don\u0027t know whether the node came from ZAPPING or from INIT, this is can lead us to some hard to debug problem, because, for example: \n\nNodes going from INIT to AVAILABLE, they may succeed by going through INIT-\u003eZAPPING-\u003eAVAIALBLE, and others could fail* if they go trough INIT-\u003eAVAILABLE directly. Now at first it will be pretty unpredictable because part of the nodes succeed and part of it failed and they are coming from different paths.\n\nSo it\u0027s very powerful to make sure that once we are in one state we have a way to predicate from which state it came from.\n\nMy suggestion here is to always pass thought ZAPPING, even if it\u0027s a non-op action.\n\n2) In this state machine, as it is, we are mixing states and actions. We only talk about states here, but in a real state machine we always need a action to transition from state to another. For example using the INIT state again, ZAPPING seems to be an action, so it would be nice to differentiate it in the diaram, maybe:\n\nINIT -\u003e [ ZAPPING ] -\u003e AVAILABLE\n\nAnother example:\n\nACTIVE -\u003e [DELETING] -\u003e DELETED\n\nIt\u0027s important to make sure that, for every state we have a action to make the transition.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"7967dda19292b8c33872e9d99777542e9ce915a2","unresolved":false,"context_lines":[{"line_number":204,"context_line":"           |        +-\u003e ZAPPING -/             |             |"},{"line_number":205,"context_line":"           |        |                          |             v"},{"line_number":206,"context_line":"           |        v                          +-------\u003e DEPLOYING"},{"line_number":207,"context_line":"           +\u003c-- DISCOVERING                    |             | "},{"line_number":208,"context_line":"           ^                                   |             v"},{"line_number":209,"context_line":"           +\u003c----------------------------------/          DEPLOYED"},{"line_number":210,"context_line":"           ^                                                 |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_c9f5c2cb","line":207,"in_reply_to":"5a890539_9055a8fb","updated":"2014-11-26 13:35:48.000000000","message":"@Lucas +1 on the mixing states and actions.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":204,"context_line":"           |        +-\u003e ZAPPING -/             |             |"},{"line_number":205,"context_line":"           |        |                          |             v"},{"line_number":206,"context_line":"           |        v                          +-------\u003e DEPLOYING"},{"line_number":207,"context_line":"           +\u003c-- DISCOVERING                    |             | "},{"line_number":208,"context_line":"           ^                                   |             v"},{"line_number":209,"context_line":"           +\u003c----------------------------------/          DEPLOYED"},{"line_number":210,"context_line":"           ^                                                 |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_0b711e0c","line":207,"in_reply_to":"5a890539_9055a8fb","updated":"2014-12-01 16:30:19.000000000","message":"Eh, I disagree about the state machine being \"too complex\" -- from my POV, it is as complex as it needs to be to account for the use cases folks have in mind for Ironic.\n\nFor point 1, it would simplify things.  My concern there involved users who do not wish to automatically ZAP nodes for whatever reason, as that is (in my mind, at least) a policy decision and not a technical one.  I would be OK with eliminating the DELETED -\u003e AVAILABLE transition as long as some way of letting users skip all or part of the ZAPPING tasks is available.\n\nFor point 2, how about:\n\n* Undecorated action \u003d Passive state, Ironic is not doing anything to the node and will not automatically transition away from it.\n* [Bracketed action] \u003d Active state, Ironic is doing something to the node and will transition to the next state automatically when it sucessfully finishes.\n* (Parenthetical action) \u003d Transient state, Ironic is not doing anything to the node and it will automatically transition to the next state.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"237b0f6b1d3c20b8c0493a13cfa4731f51d6f7af","unresolved":false,"context_lines":[{"line_number":214,"context_line":"                                      |                      |"},{"line_number":215,"context_line":"                                      |                      v"},{"line_number":216,"context_line":"                                      \\--------------------RESCUE"},{"line_number":217,"context_line":"  "},{"line_number":218,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":219,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":220,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_218e912e","line":217,"updated":"2014-11-25 10:34:13.000000000","message":"trailing whitespace","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":214,"context_line":"                                      |                      |"},{"line_number":215,"context_line":"                                      |                      v"},{"line_number":216,"context_line":"                                      \\--------------------RESCUE"},{"line_number":217,"context_line":"  "},{"line_number":218,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":219,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":220,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_ab23aabc","line":217,"in_reply_to":"5a890539_218e912e","updated":"2014-12-01 16:30:19.000000000","message":"Done","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"bb36bf16424f43560464d16a456a252cd04b3d9c","unresolved":false,"context_lines":[{"line_number":219,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":220,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":221,"context_line":"-- at the summit we talked in terms of a wait flag, but that area still"},{"line_number":222,"context_line":"needs to be hashed out."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_ccf302e6","line":222,"updated":"2014-11-26 20:32:05.000000000","message":"This hashing out signaling with in the scope of this spec or should that be done on another spec?","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":219,"context_line":"signalling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":220,"context_line":"Crowbar, etc.) is handling part of the transition for any given state"},{"line_number":221,"context_line":"-- at the summit we talked in terms of a wait flag, but that area still"},{"line_number":222,"context_line":"needs to be hashed out."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_2b17ba55","line":222,"in_reply_to":"5a890539_ccf302e6","updated":"2014-12-01 16:30:19.000000000","message":"I am fine with it being done in this spec.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"02b5afccba41c5cb27ca35a154b7dc80396b8086","unresolved":false,"context_lines":[{"line_number":229,"context_line":"Data model impact"},{"line_number":230,"context_line":"-----------------"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Probably."},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"REST API impact"},{"line_number":235,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_4561a510","line":232,"updated":"2014-11-26 23:38:54.000000000","message":"I\u0027d love to see the addition of a task_state field for tracking things like what\u0027s actually going on in ZAPPING, PREBOOTING, possibly other states. It should just be an indication to the operator of what\u0027s going on during long running operations. If it isn\u0027t added here, I\u0027ll need to add it in the zapping spec.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":229,"context_line":"Data model impact"},{"line_number":230,"context_line":"-----------------"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Probably."},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"REST API impact"},{"line_number":235,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_8670a5a5","line":232,"in_reply_to":"5a890539_4561a510","updated":"2014-12-01 16:30:19.000000000","message":"Ideally, what I would like to see exposed for ZAPPING, PREBOOTING, and DEPLOYING is an ordered list of tasks which can be pending, active, succeeded, or failed.  My concerns there revolve mainly around where that list comes from.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"bb36bf16424f43560464d16a456a252cd04b3d9c","unresolved":false,"context_lines":[{"line_number":292,"context_line":"Work Items"},{"line_number":293,"context_line":"----------"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Lots of discussion in comments to be done."},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Dependencies"},{"line_number":298,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_2c9f2667","line":295,"updated":"2014-11-26 20:32:05.000000000","message":"we may want to start listing existing areas of the code that will require updating as a result of this spec. we may be able to get some parallel work started.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":292,"context_line":"Work Items"},{"line_number":293,"context_line":"----------"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Lots of discussion in comments to be done."},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Dependencies"},{"line_number":298,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_065cb518","line":295,"in_reply_to":"5a890539_2c9f2667","updated":"2014-12-01 16:30:19.000000000","message":"Give me comments about them, and I will add them.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"bb36bf16424f43560464d16a456a252cd04b3d9c","unresolved":false,"context_lines":[{"line_number":303,"context_line":"Testing"},{"line_number":304,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"We have a lot of talking to do about this."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_2cd1e62f","line":306,"updated":"2014-11-26 20:32:05.000000000","message":"we should be thinking about this section now.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"7ebc0d2532ebb555ffccc1f3462245e0d3204ece","unresolved":false,"context_lines":[{"line_number":303,"context_line":"Testing"},{"line_number":304,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"We have a lot of talking to do about this."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a890539_86a7c50a","line":306,"in_reply_to":"5a890539_2cd1e62f","updated":"2014-12-01 16:30:19.000000000","message":"Ditto.","commit_id":"a987f32d8e1f0f8b0d3b3cee4b605aff0864a95a"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e30b06a990817ab66fc6b91b98bdc6acfe4bf24","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_dd8d17d5","line":58,"updated":"2014-12-01 19:38:05.000000000","message":"That may be unrelated, but I have a use-case for discoverd, when it actually assigns the credentials. Not sure if we should fit this case into the state machine though, because OOB will never do it...","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"ce3d419c6f1a794f421915956153427e002ba3a5","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_7888b1c6","line":58,"in_reply_to":"5a890539_5885b505","updated":"2014-12-01 19:59:56.000000000","message":"I\u0027m trying to avoid it, because e.g. discoverd does not know a good driver to use. It will also seriously complicate discoverd. Another idea is to allow discoverd to work on a node in ENROLL state (and move it to INIT state). So that OOB discovery only works INIT -\u003e DISCOVERY -\u003e INIT, while discoverd may work also ENROLL -\u003e DISCOVERY -\u003e INIT. That requires minimal changes to discoverd and no changes to the state machine.","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"2d7a751a848b60f82b05234a47929f47a0def20f","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":56,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":57,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":58,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_5885b505","line":58,"in_reply_to":"5a890539_dd8d17d5","updated":"2014-12-01 19:49:56.000000000","message":"Hmmm... would it not be easier for discoverd to create the node itself?","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e30b06a990817ab66fc6b91b98bdc6acfe4bf24","unresolved":false,"context_lines":[{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"},{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_d817e543","line":62,"updated":"2014-12-01 19:38:05.000000000","message":"not \u0027enrolling\u0027, but moving from ENROLL to INIT. SOo I think INITFAIL could be a much better name.","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"ce3d419c6f1a794f421915956153427e002ba3a5","unresolved":false,"context_lines":[{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"},{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_b8a93926","line":62,"in_reply_to":"5a890539_18924d4b","updated":"2014-12-01 19:59:56.000000000","message":"ok, I\u0027ll be waiting for the next patchset :)","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"2d7a751a848b60f82b05234a47929f47a0def20f","unresolved":false,"context_lines":[{"line_number":59,"context_line":"  ENROLLFAIL."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"ENROLLFAIL"},{"line_number":62,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"},{"line_number":63,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":64,"context_line":"  to resolve the situation."},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_18924d4b","line":62,"in_reply_to":"5a890539_d817e543","updated":"2014-12-01 19:49:56.000000000","message":"Please note that the substantive objections raised in the last patch set still apply -- I only did spelling, state machine diagrams, and tox fixes for this change.","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":7623,"name":"Erwan Velu","email":"erwan@enovance.com","username":"erwan"},"change_message_id":"95cbb5c72a0396d0de3806ee6eef4f3b90497848","unresolved":false,"context_lines":[{"line_number":206,"context_line":"  ENROLL \u003e-+-\u003e INIT +-----\u003e------+\u003e AVAILABLE -+-\u003ePREBOOTING \\"},{"line_number":207,"context_line":"           ^        |            ^    ^        |             v"},{"line_number":208,"context_line":"           |        |            |    |        |         PREBOOTED"},{"line_number":209,"context_line":"           |        +-\u003e ZAPPING -/    |        |             |"},{"line_number":210,"context_line":"           |        |      ^          |        |             v"},{"line_number":211,"context_line":"           |        v      \\----------+        +-------\u003e DEPLOYING"},{"line_number":212,"context_line":"           +\u003c-- DISCOVERING           |        |             |"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a890539_e3f6b25c","line":209,"updated":"2014-12-01 20:55:22.000000000","message":"Couldn\u0027t we get zapping on the main path and making it optional by having an empty body by default ? That would avoid creating alternatives paths and make the logic simplier ?\n\nPassing always through zapping with no code by default but implemented if required ?","commit_id":"6394d6f8722972ea46955809e7b3258ed773ba71"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e5afb261b3fe59dba8de9638e1d7bfe06cc5027","unresolved":false,"context_lines":[{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"},{"line_number":61,"context_line":"  to INIT."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"ENROLLFAIL"},{"line_number":64,"context_line":"  If enrolling a node fails for some reason, Ironic will transition"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_7220cdf8","line":61,"updated":"2014-12-01 21:38:25.000000000","message":"Why overcomplicate? We used to have it pretty straightforward: every node is ENROLL in the beginning, moving to INIT requires manual intervention and passing validation. \"enroll method\" is called \"validate\" already.\n\nFor now it reads like \"just after `create` call, Ironic will validate a node, and move it to failed state, if it fails\". I see no point in this. Our quickstart guide is doing enrolling in several steps, so does devstack.","commit_id":"c5651f7ccaef829899301c2172f632844051a775"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e5afb261b3fe59dba8de9638e1d7bfe06cc5027","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  driver and credentials passed in at node create time, the node will"},{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"},{"line_number":72,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_128309cd","line":73,"updated":"2014-12-01 21:38:25.000000000","message":"That\u0027s right and on this transition we should have a validation.","commit_id":"c5651f7ccaef829899301c2172f632844051a775"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e5afb261b3fe59dba8de9638e1d7bfe06cc5027","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":106,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_924d39c7","line":108,"updated":"2014-12-01 21:38:25.000000000","message":"Why PREBOOTING? and how do you expect e.g. discoverd to figure out?","commit_id":"c5651f7ccaef829899301c2172f632844051a775"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2e5afb261b3fe59dba8de9638e1d7bfe06cc5027","unresolved":false,"context_lines":[{"line_number":117,"context_line":"  to be provisioned. From AVAILABLE, nodes can transition to:"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":120,"context_line":"    and you have not already done so."},{"line_number":121,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"},{"line_number":122,"context_line":"    not severely impact how long the node requester has to wait for"},{"line_number":123,"context_line":"    the node."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_d2c6e115","line":120,"updated":"2014-12-01 21:38:25.000000000","message":"right, so there should not be a direct transition to PREBOOTING from AVAILABLE","commit_id":"c5651f7ccaef829899301c2172f632844051a775"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"A proposal for the New Ironic State Machine."},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/new-ironic-state-machine"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_e8976ae9","line":8,"updated":"2014-12-02 15:45:26.000000000","message":"this is just a nit, but I notice it every time I look at the list of approved specs [1]. This is the only one that ends in a period. [Yikes, I can\u0027t believe I\u0027m mentioning this.]\n\n[1] http://docs-draft.openstack.org/28/133828/7/check/gate-ironic-specs-docs/2e2b66a/doc/build/html/","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":49,"context_line":"  the only thing Ironic knows about it is that it exists, and Ironic"},{"line_number":50,"context_line":"  cannot take any further action by itself.  Once Ironic has verified"},{"line_number":51,"context_line":"  that it can manage the node using the driver and credentials passed"},{"line_number":52,"context_line":"  in as part of the node create API call, the node should transition"},{"line_number":53,"context_line":"  to INIT.  If Ironic determines that it cannot manage the node with"},{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_2677ccd5","line":52,"updated":"2014-12-02 15:45:26.000000000","message":"are we going to impose that the credentials be passed in the node-create call, or continue to allow node-create \u0026 node-update calls? (If the user has to explicitly validate then I think we\u0027re ok with node-create \u0026 node-update.)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"f1a3d7343fc239c1a661835db38062656b844786","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_230c1e42","line":57,"updated":"2014-12-02 14:40:19.000000000","message":"@Devananda +1","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_282332a8","line":57,"updated":"2014-12-01 22:41:46.000000000","message":"I don\u0027t think we should trigger a method on every update. Perhaps we should make the transition from ENROLL to INIT to be a manual step (API call. Passive state) and as part of the transition we can validate the properties.\n\nAlso it would be nice to be able to trigger the node introspection (discovering) from ENROLL.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"32ced1f2d20b6ccf022c3b97c1eb77822208ef12","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_8b4a6053","line":57,"updated":"2014-12-01 22:59:19.000000000","message":"I suggested this on IRC already, as well :)\n\nI think having ENROLL be a \"static\" state, requiring an API call to VALIDATE it, thus transitioning to a VALIDATING state while that is performed. The VALIDATING state, on failure, returns to ENROLL with a last_error message, and on success, transitions to INIT.  In picture form:\n\nENROLL -\u003e [VALIDATING] -\u003e (ENROLLED) -\u003e INIT","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"78768c05463a74283ec6cebc9c7b574e0443abe7","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_46cbf871","line":57,"in_reply_to":"5a890539_230c1e42","updated":"2014-12-02 14:51:35.000000000","message":"Will do.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"6c77a042b33eb55a8dba342c4a0ddcbdbbec083f","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_48531e6c","line":57,"in_reply_to":"5a890539_282332a8","updated":"2014-12-01 22:48:12.000000000","message":"You are not alone. :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"ae04f7be01af3b6a4ee29654d811e50dfd3a3ea4","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_e31f7f59","line":57,"in_reply_to":"5a890539_8b4a6053","updated":"2014-12-02 09:40:45.000000000","message":"Devananda ++","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  the passed-in driver and credentials, the node will transition to"},{"line_number":55,"context_line":"  ENROLLFAIL.  As far as mechanics go, I would propose that each"},{"line_number":56,"context_line":"  driver have an enroll method that is called each time a node"},{"line_number":57,"context_line":"  property is updated while the node is in ENROLLED. Once all the"},{"line_number":58,"context_line":"  enroll methods for a driver have their required parameters, they"},{"line_number":59,"context_line":"  reach out and see if they can manage the node.  If any driver"},{"line_number":60,"context_line":"  cannot, the node goes to ENROLLFAIL.  If they all can, the node goes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_266d0c33","line":57,"in_reply_to":"5a890539_e31f7f59","updated":"2014-12-02 15:45:26.000000000","message":"++ for this being a passive state. Ironic drivers already have validate(), this would be a different (probably subset) of that validate() to be done in this VALIDATING state.\n\nMaybe some other word than \u0027validating\u0027 might be better. \u0027authenticating\u0027? \u0027enrolling\u0027? ENROLL -\u003e [ENROLLING] -\u003e (ENROLLED) -\u003e INIT","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"f1a3d7343fc239c1a661835db38062656b844786","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":66,"context_line":"  to resolve the situation."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"INIT"},{"line_number":69,"context_line":"  Once Ironic has verified that it can manage the node using the"},{"line_number":70,"context_line":"  driver and credentials passed in at node create time, the node will"},{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_83ff9201","line":68,"updated":"2014-12-02 14:40:19.000000000","message":"@Devananda +1","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"32ced1f2d20b6ccf022c3b97c1eb77822208ef12","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":66,"context_line":"  to resolve the situation."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"INIT"},{"line_number":69,"context_line":"  Once Ironic has verified that it can manage the node using the"},{"line_number":70,"context_line":"  driver and credentials passed in at node create time, the node will"},{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_ab455c44","line":68,"updated":"2014-12-01 22:59:19.000000000","message":"Given that this state simply indicates \"ironic has verified that it can manage teh node\", I would like to suggest that it be renamed to \"MANAGED\"","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":66,"context_line":"  to resolve the situation."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"INIT"},{"line_number":69,"context_line":"  Once Ironic has verified that it can manage the node using the"},{"line_number":70,"context_line":"  driver and credentials passed in at node create time, the node will"},{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_66e1d49a","line":68,"in_reply_to":"5a890539_2baecc98","updated":"2014-12-02 15:45:26.000000000","message":"wrt the comments in the ENROLL, maybe we want something like ENROLL -\u003e [MANAGING] -\u003e (MANAGED)\n\nOr what about calling this state \u0027ENROLLED\u0027?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"51fd7c63a6e26ee47f3425294861f83e19ac80b9","unresolved":false,"context_lines":[{"line_number":65,"context_line":"  the node to ENROLLFAIL, and operator intervention will be required"},{"line_number":66,"context_line":"  to resolve the situation."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"INIT"},{"line_number":69,"context_line":"  Once Ironic has verified that it can manage the node using the"},{"line_number":70,"context_line":"  driver and credentials passed in at node create time, the node will"},{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_2baecc98","line":68,"in_reply_to":"5a890539_ab455c44","updated":"2014-12-01 23:13:37.000000000","message":"+1","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":71,"context_line":"  be transitioned to INIT and (optionally) powered off.  Nodes must be"},{"line_number":72,"context_line":"  transitioned out of INIT by an API call -- Ironic should not do this"},{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_ab2e3c8a","line":74,"updated":"2014-12-02 15:45:26.000000000","message":"Is that the only state that it can be transitioned to from INIT? Can the API caller transition the node to DISCOVERING, PREBOOTING, or AVAILABLE?\n\nOtherwise the API caller will have to know to call zapping (even if they don\u0027t want to zap)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"f1a3d7343fc239c1a661835db38062656b844786","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_361aa718","line":76,"updated":"2014-12-02 14:40:19.000000000","message":"@Lucas +1 on the immediate clean-up.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"32ced1f2d20b6ccf022c3b97c1eb77822208ef12","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_cb7388b2","line":76,"updated":"2014-12-01 22:59:19.000000000","message":"Some good conversations were had today that suggest this state is conflating two unrelated activities:\n- clean up\n- reconfigure\n\nThis conflation is probably because both types of things require similar actions and take a similar amount of time. Knowing *what* is happening on the node is important, but does not necessarily indicate *why* it is happening. No concrete suggestion here yet, just something I\u0027m noodling on ...","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"78768c05463a74283ec6cebc9c7b574e0443abe7","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_1c20789a","line":76,"in_reply_to":"5a890539_abbe3cac","updated":"2014-12-02 14:51:35.000000000","message":"Surely that is more of a policy thing than sumething Ironic should unilaterally enforce?  I mean, it is a good policy, but there are legit reasons to not autoclean straight off.  Many of them involve detectives and lawyers.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"51fd7c63a6e26ee47f3425294861f83e19ac80b9","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  by itself.  In the INIT state, an API caller can transition the node"},{"line_number":74,"context_line":"  to ZAPPING."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"ZAPPING"},{"line_number":77,"context_line":"  Nodes in the ZAPPING state are performing (potentially) long-running and"},{"line_number":78,"context_line":"  destructive tasks, such as:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_abbe3cac","line":76,"in_reply_to":"5a890539_cb7388b2","updated":"2014-12-01 23:13:37.000000000","message":"Right, the only thing we have to take care is making sure that the cleaning happens straight after the node have been deleted so that sensitive data gets erased as quick as possible.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":82,"context_line":"  * updating firmware,"},{"line_number":83,"context_line":"  * going through burn in."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"  Magement of tasks for ZAPPING shal be handled as outlined in `the"},{"line_number":86,"context_line":"  zapping spec \u003chttps://review.openstack.org/#/c/102685/\u003e`.  Failure"},{"line_number":87,"context_line":"  of any ZAPPING task will cause the node to transition to ZAPFAIL."},{"line_number":88,"context_line":"  ZAPPING tasks must not rely on the information in node.properties"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_e63784fc","line":85,"updated":"2014-12-02 15:45:26.000000000","message":"\u0027Magement\u0027 -\u003e \u0027Management\u0027\n\u0027shal\u0027 -\u003e \u0027shall\u0027","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  Once all tasks have completed successfully, Ironic will transition"},{"line_number":93,"context_line":"  the node to DISCOVERING to update the node properties to reflect any"},{"line_number":94,"context_line":"  OS visible hardware changes made during ZAPPING."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"ZAPFAIL"},{"line_number":97,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_91c19c50","line":94,"updated":"2014-12-02 15:45:26.000000000","message":"I almost wonder, if it looks like there is a pattern wrt the state machine, whether we should have a \u0027zapped\u0027 passive state. \n\n(I\u0027m wondering if zapping should go automatically to introspecting.)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  If zapping a node fails for some reason, Ironic will transition the"},{"line_number":98,"context_line":"  node to ZAPFAIL, and operator intervention will be required to"},{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_d187a45f","line":100,"updated":"2014-12-02 15:45:26.000000000","message":"If maintenance mode is separate/outside of the state machine, maybe we shouldn\u0027t mention it here. If we mention it, then I\u0027d want to know for all the *FAIL states, whether the node is placed in maintenance mode or not. I mean, I do want to know, but I don\u0027t know if that is something we want to mention in this spec or not ;)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_28b7b2f6","line":102,"updated":"2014-12-01 22:41:46.000000000","message":"Nit: but I think we should call it INTROSPECTING. Just to avoid the whole confusion between discover vs. introspection. (Or interrogation, something else but discover)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"6c77a042b33eb55a8dba342c4a0ddcbdbbec083f","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c8038e74","line":102,"in_reply_to":"5a890539_28b7b2f6","updated":"2014-12-01 22:48:12.000000000","message":"What about SPANISH_INQUISITION?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"6229b066cddb8653dd7dff5e2ad41d2ba7e376df","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c6360803","line":102,"in_reply_to":"5a890539_7c625cda","updated":"2014-12-02 15:01:37.000000000","message":"A-ha, nice!\n\nBut still, without the voice intonation and/or body language you can be easily misinterpreted as being rude with such comments, especially in semi-public places like this one :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"ae04f7be01af3b6a4ee29654d811e50dfd3a3ea4","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_2340a734","line":102,"in_reply_to":"5a890539_c11449eb","updated":"2014-12-02 09:40:45.000000000","message":"Yeah, I already asked Nisha to rename in the discovery spec :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"f91bc83d29cd38f4a5d808c604492930be9c6ad8","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_ebd2045a","line":102,"in_reply_to":"5a890539_c8038e74","updated":"2014-12-01 23:07:08.000000000","message":"I can understand the sarcasm, but you should at least read some of this: http://en.wikipedia.org/wiki/Poe%27s_law\n\nWe have been talking about the disambiguating of the term \"discovery\" for a while as you can see here: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048810.html\n\nAnd we just agreed on having a InstrospectionInterface at the meeting, also there\u0027s a ML thread about it: http://lists.openstack.org/pipermail/openstack-dev/2014-November/051618.html\n\nSo I think INTROSPECTING is actually a valid suggestion and SPANISH_INQUISITION is not :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"4b13e5cefe2d6584eb007a24b50630764baddcca","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c11449eb","line":102,"in_reply_to":"5a890539_ebd2045a","updated":"2014-12-02 00:30:43.000000000","message":"I agree with Lucas here I think INTROSPECTING would be cleaner here","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"78768c05463a74283ec6cebc9c7b574e0443abe7","unresolved":false,"context_lines":[{"line_number":99,"context_line":"  resolve the situation.  Transitioning to ZAPFAIL will also place the"},{"line_number":100,"context_line":"  node into maintenance mode."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"DISCOVERING"},{"line_number":103,"context_line":"  DISCOVERING will utilize node introspection to update"},{"line_number":104,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_7c625cda","line":102,"in_reply_to":"5a890539_ebd2045a","updated":"2014-12-02 14:51:35.000000000","message":"That was not sarcasm, that was a Monty Python shoutout.  Most unexpected. :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"ae04f7be01af3b6a4ee29654d811e50dfd3a3ea4","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":106,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c37603a3","line":108,"updated":"2014-12-02 09:40:45.000000000","message":"Why moving from discovery to PREBOOTING? I think it should be done via AVAILABLE. Otherwise e.g. how will discoverd figure out what state to move node to after successful discovery?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"719d44b56dedf69bcfcdf154fc98b83813ad19d0","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":106,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_92e0ba27","line":108,"in_reply_to":"5a890539_91d43cea","updated":"2014-12-02 16:09:55.000000000","message":"I would suggest to always go from DISCOVERING-\u003ePREBOOTING, because PREBOOTING is configure per node AFAIUI. So if PREBOOTING is not configured for a given node it can be non-op and transition to AVAILABLE directly.\n\nThat way we guarantee that the node is always being transition through that route and avoid confusion with multipath.\n\nOtherwise if we move from DISCOVERING to AVAILABLE directly we will end up skipping the PREBOOTING phase (even when a node is configured to be prebooted).\n\nMy 0.2cents","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":106,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_91d43cea","line":108,"in_reply_to":"5a890539_c37603a3","updated":"2014-12-02 15:45:26.000000000","message":"+1 with Dmitry. Since AVAILABLE -\u003e [PREBOOTING] is possible, do we need this? (Or is it cuz nodes that are AVAILABLE can be scheduled by nova, and someone may want to do prebooting before that?)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"77bf468f4f9d1847c06eadfc3d6b608ee5655912","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":106,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c9d0d455","line":108,"in_reply_to":"5a890539_c37603a3","updated":"2014-12-02 16:47:13.000000000","message":"Tell me what you need.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"4b13e5cefe2d6584eb007a24b50630764baddcca","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  discovery fails, the node will transition to DISCOVERYFAIL."},{"line_number":108,"context_line":"  Otherwise, the node can transition to AVAILABLE or PREBOOTING."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"DISCOVERYFAIL"},{"line_number":111,"context_line":"  If discovery fails for some reason, Ironic will transition the node"},{"line_number":112,"context_line":"  to DISCOVERYFAIL, and operator intervention will be required to"},{"line_number":113,"context_line":"  resolve the situation."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_41b779f5","line":110,"updated":"2014-12-02 00:30:43.000000000","message":"if above is renamed this should become INTROSPECTIONFAIL","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":117,"context_line":"  to be provisioned. From AVAILABLE, nodes can transition to:"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  * PREBOOTING if you need a running OS to make node config changes,"},{"line_number":120,"context_line":"    and you have not already done so."},{"line_number":121,"context_line":"  * DEPLOYING if all your changes can be made out of band, and will"},{"line_number":122,"context_line":"    not severely impact how long the node requester has to wait for"},{"line_number":123,"context_line":"    the node."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_91defcd8","line":120,"updated":"2014-12-02 15:45:26.000000000","message":"I find it odd that AVAILABLE -\u003e [PREBOOTING], and [PREBOOTING] -\u003e AVAILABLE\n\nI saw a comment from Josh wanting this cuz he didn\u0027t want to go from AVAILABLE -\u003e INIT -\u003e [ZAPPING] -\u003e.. -\u003e [PREBOOTING] -\u003e AVAILABLE\n\nIt seems like people will want to no-op zapping/introspecting/prebooting sometimes like in Josh\u0027s case.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":12315,"name":"Bertie Fulton","email":"bertiefulton@yahoo.co.uk","username":"bertie.fultonsap.com"},"change_message_id":"f1a3d7343fc239c1a661835db38062656b844786","unresolved":false,"context_lines":[{"line_number":173,"context_line":"  otherwise running a workload, but that has been booted into a"},{"line_number":174,"context_line":"  different environment for some other (usually troubleshooting or"},{"line_number":175,"context_line":"  maintenance related) reason.  Nodes in RESCUE can transition back to"},{"line_number":176,"context_line":"  ACTIVE or to DELETING."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"DELETING"},{"line_number":179,"context_line":"  Nodes in DELETING state are being torn down from running an active"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_d9a4340a","line":176,"updated":"2014-12-02 14:40:19.000000000","message":"Are we able to perform automated maintenance tasks through Ironic in RESCUE mode or will this mode always be for manual or external system interaction?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":173,"context_line":"  otherwise running a workload, but that has been booted into a"},{"line_number":174,"context_line":"  different environment for some other (usually troubleshooting or"},{"line_number":175,"context_line":"  maintenance related) reason.  Nodes in RESCUE can transition back to"},{"line_number":176,"context_line":"  ACTIVE or to DELETING."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"DELETING"},{"line_number":179,"context_line":"  Nodes in DELETING state are being torn down from running an active"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_2ce7ab13","line":176,"updated":"2014-12-02 15:45:26.000000000","message":"we actually have (but not used) a RescueInterface for the drivers. Wouldn\u0027t it be \u0027RESCUING\u0027 because Ironic may be doing something on/to that node then?\n\nOr maybe that\u0027s why we haven\u0027t used the interface, cuz there isn\u0027t anything that Ironic needs to do? ;)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"78768c05463a74283ec6cebc9c7b574e0443abe7","unresolved":false,"context_lines":[{"line_number":173,"context_line":"  otherwise running a workload, but that has been booted into a"},{"line_number":174,"context_line":"  different environment for some other (usually troubleshooting or"},{"line_number":175,"context_line":"  maintenance related) reason.  Nodes in RESCUE can transition back to"},{"line_number":176,"context_line":"  ACTIVE or to DELETING."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"DELETING"},{"line_number":179,"context_line":"  Nodes in DELETING state are being torn down from running an active"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_069bb066","line":176,"in_reply_to":"5a890539_d9a4340a","updated":"2014-12-02 14:51:35.000000000","message":"RESCUE is there for Nova.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":191,"context_line":"DELETED"},{"line_number":192,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":193,"context_line":"  scrubbed or had certain persistent configuration (such as RAID"},{"line_number":194,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":195,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":196,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":197,"context_line":"  to scrub the system, run it through burnin again, or perform some"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_087cb671","line":194,"updated":"2014-12-01 22:41:46.000000000","message":"If you transition to AVAILABLE directly you will miss the PREBOOTING (in case it\u0027s configured to be prebooted)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"6c77a042b33eb55a8dba342c4a0ddcbdbbec083f","unresolved":false,"context_lines":[{"line_number":191,"context_line":"DELETED"},{"line_number":192,"context_line":"  Nodes in DELETED have been torn down, but have not necessarily been"},{"line_number":193,"context_line":"  scrubbed or had certain persistent configuration (such as RAID"},{"line_number":194,"context_line":"  config) erased.  Nodes in DELETED can transition back to AVAILABLE"},{"line_number":195,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":196,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":197,"context_line":"  to scrub the system, run it through burnin again, or perform some"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_48f79e8c","line":194,"in_reply_to":"5a890539_087cb671","updated":"2014-12-01 22:48:12.000000000","message":"Yeah, I forgot to fix this verbiage.  DELETED shoudl only go to ZAPPING now.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"761e1614123c212b8491d448337de15386255e35","unresolved":false,"context_lines":[{"line_number":195,"context_line":"  (if there is no need to scrub the system), or can have tasks"},{"line_number":196,"context_line":"  enqueued on them and then transition to ZAPPING (if there is a need"},{"line_number":197,"context_line":"  to scrub the system, run it through burnin again, or perform some"},{"line_number":198,"context_line":"  other long-running task)."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_f52d87fe","line":198,"updated":"2014-12-01 22:05:20.000000000","message":"we should follow the same path as INIT and only allow nodes to transition to zapping","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c82b8e31","line":203,"updated":"2014-12-01 22:41:46.000000000","message":"It looks a bit inconsistent by the lacking of Transient state. If you look at:\n\n 1. [DEPLOYING] -\u003e (DEPLOYED) -\u003e [ACTIVE] \n 2. [DELETING] -\u003e (DELETED) -\u003e [ZAPPING]\n\nThey both have Transient states in between.\n\nThe same looks valid for other states like ZAPPING, DISCOVERING, PREBOOTING. \n\nOr maybe getting rid of Transient states?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"32ced1f2d20b6ccf022c3b97c1eb77822208ef12","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_eb7684a2","line":203,"updated":"2014-12-01 22:59:19.000000000","message":"Let\u0027s clarify this model a bit more. Take a look at how I\u0027ve represented this here, w.r.t. the state model we have today:\n\nhttp://paste.openstack.org/raw/YzaNhr2mE2QONzcgk6Gz/","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"1d34b342c0a7cdb681031d446bb7c448c870c1ce","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_9687db11","line":203,"in_reply_to":"5a890539_631f0fb8","updated":"2014-12-02 10:16:46.000000000","message":"+many, target_provision_state not being a target state was very confusing when I started with Ironic :)","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_ac60fb35","line":203,"in_reply_to":"5a890539_9687db11","updated":"2014-12-02 15:45:26.000000000","message":"Nice Deva. I think it is worth adding the current state model diagram to this spec.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"6c77a042b33eb55a8dba342c4a0ddcbdbbec083f","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_c878eefa","line":203,"in_reply_to":"5a890539_c82b8e31","updated":"2014-12-01 22:48:12.000000000","message":"Getting rid of them is probably better -- less clutter that the drivers and users have to care about that way, assuming that we don\u0027t introduce too much ambiguity that way.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"f5b945d51272e474fc80796783a6bd2fcbc50c93","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_631f0fb8","line":203,"in_reply_to":"5a890539_eb7684a2","updated":"2014-12-02 10:01:25.000000000","message":"Hi Deva,\n\nAh nice! One thing, we may want to clarify target_provision_state and provision_state. Because states like DEPLOYDONE and DELETED never actually gets to be a provision_state (which indicates the current state) and I find it a bit inconsistent. In the model we have today - when the transition succeed - having the target_provision_state as DEPLOYDONE will make the provision_state to be ACTIVE, and target_provision_state DELETED causes provision_state to be NOSTATE.\n\nIn the new state machine we may want to clarify it, and make sure that the state we are targeting is the one that we end up in in case the transition is successfully executed.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"78768c05463a74283ec6cebc9c7b574e0443abe7","unresolved":false,"context_lines":[{"line_number":200,"context_line":"In ASCII art, the state machine will look like this (ignoring error"},{"line_number":201,"context_line":"states)::"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"  [ENROLL]-\u003e INIT -\u003e [ZAPPING] -\u003e [DISCOVERING] -\u003e [PREBOOTING]"},{"line_number":204,"context_line":"               ^         ^              |               ^"},{"line_number":205,"context_line":"               |         |              v               |"},{"line_number":206,"context_line":"               \\------------------- AVAILABLE \u003c---------/"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_a6dd7c16","line":203,"in_reply_to":"5a890539_eb7684a2","updated":"2014-12-02 14:51:35.000000000","message":"I am going to steal that and update the current ASCII art to use its conventions.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5664fc4098eb34c93533ca1fc122d2eabdf17016","unresolved":false,"context_lines":[{"line_number":236,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":237,"context_line":"signaling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":238,"context_line":"Crowbar, etc.) is handling part of the transition for any given"},{"line_number":239,"context_line":"state. At the summit we talked in terms of a wait flag, but that area still"},{"line_number":240,"context_line":"needs to be hashed out."},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_17703ca3","line":239,"updated":"2014-12-02 15:45:26.000000000","message":"Any passive, active, or transient state?","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"77bf468f4f9d1847c06eadfc3d6b608ee5655912","unresolved":false,"context_lines":[{"line_number":236,"context_line":"In addition to state machine changes, Ironic needs a mechanism for"},{"line_number":237,"context_line":"signaling that an external tool (such as Chef, Puppet, Ansible,"},{"line_number":238,"context_line":"Crowbar, etc.) is handling part of the transition for any given"},{"line_number":239,"context_line":"state. At the summit we talked in terms of a wait flag, but that area still"},{"line_number":240,"context_line":"needs to be hashed out."},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_696fe092","line":239,"in_reply_to":"5a890539_17703ca3","updated":"2014-12-02 16:47:13.000000000","message":"I am dropping the wait flag stuff for now.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":272,"context_line":"Security impact"},{"line_number":273,"context_line":"---------------"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Probably not, assuming perfect coding."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Other end user impact"},{"line_number":278,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_08abd689","line":275,"updated":"2014-12-01 22:41:46.000000000","message":"It improves security since now we are considering erasing the [sensible] data from previous tenants.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"77bf468f4f9d1847c06eadfc3d6b608ee5655912","unresolved":false,"context_lines":[{"line_number":272,"context_line":"Security impact"},{"line_number":273,"context_line":"---------------"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Probably not, assuming perfect coding."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Other end user impact"},{"line_number":278,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_a9fc68b6","line":275,"in_reply_to":"5a890539_08abd689","updated":"2014-12-02 16:47:13.000000000","message":"I was thinking more along the lines of attack vectors exploiting API misdesign.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"d93da26e49d6ed22a9e76f4a76ead59d2d823d5a","unresolved":false,"context_lines":[{"line_number":287,"context_line":"Performance Impact"},{"line_number":288,"context_line":"------------------"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Ditto."},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Other deployer impact"},{"line_number":293,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a890539_688ffa2e","line":290,"updated":"2014-12-01 22:41:46.000000000","message":"Prebooting is a state where optimization to the deployment can be done, I node already prebooted will be deployed faster. So I believe the state machine allows improvements on performance.","commit_id":"9c3ba671aa0cbe07d2fa92e4f65ca61a6886c56d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"7901327a488e9b89760f02d52c0c3cd473c175f1","unresolved":false,"context_lines":[{"line_number":151,"context_line":""},{"line_number":152,"context_line":"  Management of tasks for ZAPPING shall be handled as outlined in `the"},{"line_number":153,"context_line":"  zapping spec \u003chttps://review.openstack.org/#/c/102685/\u003e`."},{"line_number":154,"context_line":"  ZAPPING tasks must not rely on the information in node.properties"},{"line_number":155,"context_line":"  being correct beyond the information that each driver needs to"},{"line_number":156,"context_line":"  connect to the system."},{"line_number":157,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a890539_bf13b1ff","line":154,"updated":"2014-12-02 21:40:01.000000000","message":"Note that driver-specific information, eg. what is needed to connect to and manage the node, should all be in the node.driver_info field. \n\nnode.properties could be completely and validly empty at this point.","commit_id":"050f9ed79091a29acf9e4613f7a33198673929ca"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"353dc965f1242eb3a8b4c0ab608b0cb8ac42d55a","unresolved":false,"context_lines":[{"line_number":53,"context_line":"          +                   +---\u003e[DEPLOYING//DEPLOYDONE]----\u003eDEPLOYFAIL//NONE"},{"line_number":54,"context_line":"     [DELETING//DELETED]      |       +"},{"line_number":55,"context_line":"          ^                   |       v"},{"line_number":56,"context_line":"          |          R:rebuild|    (DEPLOYDONE//DEPLOYDONE)"},{"line_number":57,"context_line":"          |                   |       +"},{"line_number":58,"context_line":"          |                   |       v"},{"line_number":59,"context_line":"          |                   +---+ACTIVE//NONE"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_7017aaa3","line":56,"updated":"2014-12-03 10:52:08.000000000","message":"DEPLOYDONE doesn\u0027t get to be a provision_state, it\u0027s a target_provision_state that once the work is finished it moves to provision_state ACTIVE directly\n\nSame for DELETED on L51","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"f12b848a64a472201ed834652f465fc34e429fad","unresolved":false,"context_lines":[{"line_number":53,"context_line":"          +                   +---\u003e[DEPLOYING//DEPLOYDONE]----\u003eDEPLOYFAIL//NONE"},{"line_number":54,"context_line":"     [DELETING//DELETED]      |       +"},{"line_number":55,"context_line":"          ^                   |       v"},{"line_number":56,"context_line":"          |          R:rebuild|    (DEPLOYDONE//DEPLOYDONE)"},{"line_number":57,"context_line":"          |                   |       +"},{"line_number":58,"context_line":"          |                   |       v"},{"line_number":59,"context_line":"          |                   +---+ACTIVE//NONE"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_a661ae3a","line":56,"updated":"2014-12-04 00:24:24.000000000","message":"Yes, Lucas is correct. The current implementation does not adhere completely to the new semantics. \n\nDELETED is actually a return value from node.driver.deploy.tear_down; when conductor _do_node_tear_down() receives this return value, it updates the node,.provision_state to NOSTATE immediately.\n\nDitto for DEPLOYDONE.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":53,"context_line":"          +                   +---\u003e[DEPLOYING//DEPLOYDONE]----\u003eDEPLOYFAIL//NONE"},{"line_number":54,"context_line":"     [DELETING//DELETED]      |       +"},{"line_number":55,"context_line":"          ^                   |       v"},{"line_number":56,"context_line":"          |          R:rebuild|    (DEPLOYDONE//DEPLOYDONE)"},{"line_number":57,"context_line":"          |                   |       +"},{"line_number":58,"context_line":"          |                   |       v"},{"line_number":59,"context_line":"          |                   +---+ACTIVE//NONE"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_d5a122f8","line":56,"in_reply_to":"5a890539_7017aaa3","updated":"2014-12-03 14:54:19.000000000","message":"I stole this graph straight from Deva.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"          +                   +---\u003e[DEPLOYING//DEPLOYDONE]----\u003eDEPLOYFAIL//NONE"},{"line_number":54,"context_line":"     [DELETING//DELETED]      |       +"},{"line_number":55,"context_line":"          ^                   |       v"},{"line_number":56,"context_line":"          |          R:rebuild|    (DEPLOYDONE//DEPLOYDONE)"},{"line_number":57,"context_line":"          |                   |       +"},{"line_number":58,"context_line":"          |                   |       v"},{"line_number":59,"context_line":"          |                   +---+ACTIVE//NONE"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_44c49e5f","line":56,"in_reply_to":"5a890539_d5a122f8","updated":"2014-12-03 16:47:45.000000000","message":"hmm, DEPLOYDONE \u0026 DELETED are momentary states, so yeah, maybe it is clearer if those are the \u0027current\u0027, and the target states are what Ironic transitions to, so ACTIVE and NOSTATE respectively.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* STATE indicates a passive state. Ironic will not transition unless"},{"line_number":70,"context_line":"  receiving a request via the API."},{"line_number":71,"context_line":"* R:request indicates the request which must be passed to the API to"},{"line_number":72,"context_line":"  initiate a transition out of a static state."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Ironic\u0027s API presents two fields for the provision_state of a node:"},{"line_number":75,"context_line":"current and target.  Thus, in this diagram, all states are represented as"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_8474c69c","line":72,"updated":"2014-12-03 16:47:45.000000000","message":"\u0027static\u0027 -\u003e \u0027passive\u0027","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"dcbc7dace2e22e1177e5bc5d98b166ae7e630e29","unresolved":false,"context_lines":[{"line_number":69,"context_line":"* STATE indicates a passive state. Ironic will not transition unless"},{"line_number":70,"context_line":"  receiving a request via the API."},{"line_number":71,"context_line":"* R:request indicates the request which must be passed to the API to"},{"line_number":72,"context_line":"  initiate a transition out of a static state."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Ironic\u0027s API presents two fields for the provision_state of a node:"},{"line_number":75,"context_line":"current and target.  Thus, in this diagram, all states are represented as"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_8ef30072","line":72,"in_reply_to":"5a890539_8474c69c","updated":"2014-12-03 17:00:36.000000000","message":"Will fix.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"f12b848a64a472201ed834652f465fc34e429fad","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  ENROLL -----------\u003e [VALIDAT*/MANAGED]"},{"line_number":84,"context_line":"          R:validate          |"},{"line_number":85,"context_line":"                              v"},{"line_number":86,"context_line":"                  +-------\u003eMANAGED\u003c-----------+"},{"line_number":87,"context_line":"                  |        +  + ^ |           |"},{"line_number":88,"context_line":"                  |   R:zap|  | | |R:inspect  |"},{"line_number":89,"context_line":"                  +        |  | | |           +"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_c664fa4a","line":86,"updated":"2014-12-04 00:24:24.000000000","message":"@Erwan, please provide a citation which states that a finite state machine can not have multiple paths to arrive at a single state. I believe all your statements to this effect are incorrect. \n\nFurthermore, I do not believe this presents \"a serious issue\" for Ironic.\n\n@Josh, ++","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":7623,"name":"Erwan Velu","email":"erwan@enovance.com","username":"erwan"},"change_message_id":"3eda90b09d7bbcdde46ee388ca0fedc213d7aa94","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  ENROLL -----------\u003e [VALIDAT*/MANAGED]"},{"line_number":84,"context_line":"          R:validate          |"},{"line_number":85,"context_line":"                              v"},{"line_number":86,"context_line":"                  +-------\u003eMANAGED\u003c-----------+"},{"line_number":87,"context_line":"                  |        +  + ^ |           |"},{"line_number":88,"context_line":"                  |   R:zap|  | | |R:inspect  |"},{"line_number":89,"context_line":"                  +        |  | | |           +"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_a77fffdd","line":86,"updated":"2014-12-03 17:54:11.000000000","message":"If we intend to get a FSM, the MANAGED state doesn\u0027t define anything as it could be the result of a 3 different entry point. VALID/ZAP/INSPECT from a FSM perspective, that\u0027s a serious issue here .\n\nA state should have a transition to another state. It cannot hide various different internal states.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1fbb92344a4982061ad9e56f5d58af0d04d40937","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  ENROLL -----------\u003e [VALIDAT*/MANAGED]"},{"line_number":84,"context_line":"          R:validate          |"},{"line_number":85,"context_line":"                              v"},{"line_number":86,"context_line":"                  +-------\u003eMANAGED\u003c-----------+"},{"line_number":87,"context_line":"                  |        +  + ^ |           |"},{"line_number":88,"context_line":"                  |   R:zap|  | | |R:inspect  |"},{"line_number":89,"context_line":"                  +        |  | | |           +"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_246ce4cf","line":86,"in_reply_to":"5a890539_95ef8cb0","updated":"2014-12-03 20:29:17.000000000","message":"josh +1.  FSMs don\u0027t have memory, but we have logfiles and databases, and when troubleshooting I care about what is in the logs and what I think the state machine should have done is a secondary concern.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"38eb42ed5aacfa376cdf25e53f6e35100af5fc19","unresolved":false,"context_lines":[{"line_number":83,"context_line":"  ENROLL -----------\u003e [VALIDAT*/MANAGED]"},{"line_number":84,"context_line":"          R:validate          |"},{"line_number":85,"context_line":"                              v"},{"line_number":86,"context_line":"                  +-------\u003eMANAGED\u003c-----------+"},{"line_number":87,"context_line":"                  |        +  + ^ |           |"},{"line_number":88,"context_line":"                  |   R:zap|  | | |R:inspect  |"},{"line_number":89,"context_line":"                  +        |  | | |           +"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_95ef8cb0","line":86,"in_reply_to":"5a890539_a77fffdd","updated":"2014-12-03 18:55:04.000000000","message":"As far as a \"correct\" FSM, sure, you\u0027re right. But we have memory outside the FSM.\n\nAs far as Ironic is concerned, whether it\u0027s been inspected or not beforehand doesn\u0027t matter. If the hardware doesn\u0027t match what Ironic has stored in node.properties, it should fail in CLEANING, because you likely have a hardware failure of some kind, and you shouldn\u0027t be cleaning it. Go to CLEANFAIL, set the last_error, the operator knows what happened.\n\nSame for any ZAPPING task. I assume any ZAPPING task is going to set a hardware capability of some kind (otherwise, why did you do it if you can\u0027t schedule against it? I might be wrong here though). Again, when cleaning, you can verify the node.properties you\u0027re going to schedule against is what\u0027s reflected on the hardware. If this fails, again, you go to a failure state, set the last_error, the operator understands.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"f12b848a64a472201ed834652f465fc34e429fad","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_e6573658","line":95,"updated":"2014-12-04 00:24:24.000000000","message":"@Ruby, I initially did not see benefit to distinguishing two states here, but after discussing with Victor, Jay, and others, I was convinced of the usefulness of having two states.\n\nSome drivers may choose to no-op one or both states, or to perform the same action(s) in eachr of them. That being said, there is an operationally meaningful distinction between:\n- a node, which is not available for provisioning, is being worked on, at the explicit request of an operator\n- a node, as a result of de-provisioning, is being worked on, before it can be returned to the pool of available nodes\n\nWe have no clear semantic to express the former case today, yet we have a need to handle that use case. The only appromixation today is to use maintenance-mode.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"353dc965f1242eb3a8b4c0ab608b0cb8ac42d55a","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_fbd7fbbc","line":95,"updated":"2014-12-03 10:52:08.000000000","message":"Usually (I believe it\u0027s a good practice) in order to erase the disks in a RAID array, you break up the array first and then wipe the individual disks to be confident, because that way you don\u0027t go through the abstraction layer of the RAID.\n\nNow I see that we are moving directly from CLEANING to AVAILABLE, if we break the array to clean the disks where it is going to be recreated? Shouldn\u0027t ZAPPING be the next state after CLEANING?","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"dcbc7dace2e22e1177e5bc5d98b166ae7e630e29","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_eedac4e7","line":95,"in_reply_to":"5a890539_382b3696","updated":"2014-12-03 17:00:36.000000000","message":"Deva and I think it is a useful distinction, which is why it was split out.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"f4e1b14f3b27ad56602e955eec6ad04910f3747f","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_e30d8490","line":95,"in_reply_to":"5a890539_b531f6a3","updated":"2014-12-03 15:37:15.000000000","message":"Yeah CLEANING could rebuilt the array, tho it doesn\u0027t sounds like the right place to do it.\n\nThat\u0027s why I commented on L112 saying that patch-set #7 looks more flexible, because we have ZAPPING after the node deletion (and you can configure the priority of the tasks in the zapping state as: 1. break raid (if created), 2. erase disks, 3. rebuilt raid, 4. update firmware, 5. verify if it\u0027s correct etc... Where CLEANING sounds like a place only used for wiping the disks and that\u0027s it.\n\nEven for things like powering on the node in order to optimize deployment time (the flag for preboot) looks more like a zap_step than like a hidden step in a transition that happens between the CLEANING and AVAILABLE, because it\u0027s changing the state of the server (prebooted machines AIUI are exposed to the scheduler differently right? Like a capability or so) but is not being represented anywhere in the state machine.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_382b3696","line":95,"in_reply_to":"5a890539_e30d8490","updated":"2014-12-03 16:47:45.000000000","message":"If we ignore the words \u0027ZAP\u0027 and \u0027CLEAN\u0027, the question (to me) is whether it makes sense to distinguish two groups of actions/states. One that people may only want to do after enrolling, but not after every deletion (ZAP), and the other set of tasks to be done after enrolling and after every deletion.\n\nIf that isn\u0027t a useful distinction, then maybe we just go back to one ZAP, and the drivers themselves will code (if they want) which tasks to do, when, based on knowing the state prior to the ZAP* state.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"39d9e6590b589c176e2ddffa98932b6fdcf35bb3","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_6506c5cf","line":95,"in_reply_to":"5a890539_e6573658","updated":"2014-12-04 14:54:41.000000000","message":"++ for the two states. I was trying to figure out whether people were opposed to two states, or whether it was the names of the states. And these comments will help wrt the rationale behind the two states :-) I think it would be helpful to add the rationale to the spec somewhere. (And maybe the rationale for any other sticky issues/decisions...)","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"},{"line_number":96,"context_line":"                      ^                   +"},{"line_number":97,"context_line":"                      |                   |R:active"},{"line_number":98,"context_line":"                      +                   v"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_b531f6a3","line":95,"in_reply_to":"5a890539_fbd7fbbc","updated":"2014-12-03 14:54:19.000000000","message":"huh, I have never heard of doing that -- the RAID controllers I usually use do not allow raw access to the underlying devices at all -- the best you can get is a single-disk RAID 0.\n\nIn either case, if your CLEANING routine is smart enough to break a RAID array apart, it better be smart enough to put it back together, IMAO.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"f12b848a64a472201ed834652f465fc34e429fad","unresolved":false,"context_lines":[{"line_number":109,"context_line":"                      |                      |R:unrescue    |"},{"line_number":110,"context_line":"                      |                      |              v"},{"line_number":111,"context_line":"                      +----------------------+----------+RESCUE"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_065b6286","line":112,"updated":"2014-12-04 00:24:24.000000000","message":"I discussed PREBOOTING with Jim. It can be handled by CLEAN* putting the node into a powered-on-and-ready state.\n\nSome drivers may define CLEAN as powered-off. Other drivers may define it as powered-on. Yet other drivers may choose to have some nodes on and some nodes off, as their own optimization. We don\u0027t need to handle arbitrary cases of PREBOOTING because each driver knows what it expects from a node which it CLEANED.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"353dc965f1242eb3a8b4c0ab608b0cb8ac42d55a","unresolved":false,"context_lines":[{"line_number":109,"context_line":"                      |                      |R:unrescue    |"},{"line_number":110,"context_line":"                      |                      |              v"},{"line_number":111,"context_line":"                      +----------------------+----------+RESCUE"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_5bc72f12","line":112,"updated":"2014-12-03 10:52:08.000000000","message":"It has changed a lot since the proposed state machine up to patch-set #7[1]. What happened with PREBOOTING?\n\nI think the patch-set #7 one machine was a bit more flexible (considering some states being no-op if not implemented, like PREBOOTING)\n\n[1] https://review.openstack.org/#/c/133828/7/specs/kilo/new-ironic-state-machine.rst","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":109,"context_line":"                      |                      |R:unrescue    |"},{"line_number":110,"context_line":"                      |                      |              v"},{"line_number":111,"context_line":"                      +----------------------+----------+RESCUE"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_f5837e00","line":112,"in_reply_to":"5a890539_5bc72f12","updated":"2014-12-03 14:54:19.000000000","message":"This state machine it Deva\u0027s latest one.  IIRC, the idea is that PREBOOTING vanishes and is replaced by a flag that just does not power off when CLEANING is finished.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"f12b848a64a472201ed834652f465fc34e429fad","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_2655be4f","line":117,"updated":"2014-12-04 00:24:24.000000000","message":"Lucas is correct in as much as the state names are not constrained by Nova\u0027s instance state names.\n\nHowever, upgrading the nova.virt.ironic driver is going to be very challenging as we introduce new state names to Ironic. Further, changing the existing state names will need to be done (if it is done at all) in a backwards-compatible way.\n\nThat is to say, users will almost definitely, at some point, have to run different releases of Nova and Ironic. If the old driver can\u0027t talk to new Ironic, and the new driver can\u0027t talk to the old Ironic, how will our users ever be able to upgrade???","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"353dc965f1242eb3a8b4c0ab608b0cb8ac42d55a","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_d053fe69","line":117,"updated":"2014-12-03 10:52:08.000000000","message":"nit: when we say active state, it sounds we are talking about the ACTIVE state (the state where the tenant is on the machine)","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1fbb92344a4982061ad9e56f5d58af0d04d40937","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_c4dfa064","line":117,"in_reply_to":"5a890539_22f85d49","updated":"2014-12-03 20:29:17.000000000","message":"Right, but it is in a different project and it makes incremental upgrades that much more annoying -- this one will be annoying enough as is.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10380,"name":"Josh Gachnang","email":"josh@pcsforeducation.com","username":"JoshNang"},"change_message_id":"38eb42ed5aacfa376cdf25e53f6e35100af5fc19","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_22f85d49","line":117,"in_reply_to":"5a890539_6e7974fb","updated":"2014-12-03 18:55:04.000000000","message":"FWIW we can change what Nova expects.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"843aa11bb8f04342c7448ee5350a459675601466","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_0237e1e3","line":117,"in_reply_to":"5a890539_6e7974fb","updated":"2014-12-03 19:06:27.000000000","message":"Just correcting here, nova doesn\u0027t expects any states from Ironic, nova doesn\u0027t know it. The Nova Ironic driver does[1] looks at some particular states in Ironic, so that\u0027s under our control, the states could have any name we want.\n\nBut anyway, that was just a nit that was causing some confusion.\n\n[1] https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L655-L666","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"dcbc7dace2e22e1177e5bc5d98b166ae7e630e29","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_6e7974fb","line":117,"in_reply_to":"5a890539_7b821853","updated":"2014-12-03 17:00:36.000000000","message":"lower-case active means that Ironic is doing something to the node.  Upper-case ACTIVE is a passive state that has its name because that is what Nova expects it to have.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"f4727def3c1fad71f48c8d061247f290a2027dd2","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_0495363f","line":117,"in_reply_to":"5a890539_9e87b760","updated":"2014-12-03 16:07:23.000000000","message":"I believe the names of those states are constrained by what nova expects. :(","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_7b821853","line":117,"in_reply_to":"5a890539_9e87b760","updated":"2014-12-03 16:47:45.000000000","message":"If I understand this, you\u0027re fine with having states that are \"active states\". What you\u0027d like to change is the name of the \u0027ACTIVE\u0027 state, to something like \u0027PROVISIONED\u0027, and \u0027DELETED\u0027 -\u003e \u0027UNPROVISIONED\u0027. (Although doesn\u0027t the AVAILABLE state also qualify as being in an UNPROVISIONED state too?)","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_d595a232","line":117,"in_reply_to":"5a890539_d053fe69","updated":"2014-12-03 14:54:19.000000000","message":"If you have a better name, I am all ears.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"f4e1b14f3b27ad56602e955eec6ad04910f3747f","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Legend for the new state machine:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"[STATE*/TARGET]"},{"line_number":117,"context_line":"  STATE* indicates an active state, a momentary state, and a fail"},{"line_number":118,"context_line":"  state. The active state has an -ING suffix, the momentary state has"},{"line_number":119,"context_line":"  a -ED suffix, and the fail state has a -FAIL suffix.   In the active"},{"line_number":120,"context_line":"  state, Ironic is doing something to the node."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_9e87b760","line":117,"in_reply_to":"5a890539_d595a232","updated":"2014-12-03 15:37:15.000000000","message":"I\u0027m not a native english speaker, but I believe that PROVISIONED instead of ACTIVE and UNPROVISIONED instead of DELETED makes more sense.\n\nIf you think that the state machine represents the life of the server, saying that a server is DELETED sounds a bit odd to me, but a server being UNPROVISIONED sounds like we are taking the server back from someone else control. Because to provision something is the act of provide/give something to someone, in this case the tenant. We are giving the tenant a server (PROVISIONING) and we are taking back after the tenant have used it (UNPROVISIONING).","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"cd20e34f6c75e4e4ebe443a1b2517d2acfc52e74","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_4332ef5e","line":189,"updated":"2014-12-03 04:15:03.000000000","message":"There is no description of INSPECTFAIL.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"f4727def3c1fad71f48c8d061247f290a2027dd2","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_84dda616","line":189,"in_reply_to":"5a890539_09b0ef89","updated":"2014-12-03 16:07:23.000000000","message":"Look at the key in this spec, not in the graph Deva shared.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_554532b2","line":189,"in_reply_to":"5a890539_4332ef5e","updated":"2014-12-03 14:54:19.000000000","message":"Indeed.  Look at the key for the new state machine to see why,","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":11297,"name":"Nisha Agarwal","email":"agarwalnisha1980@gmail.com","username":"Nisha"},"change_message_id":"63deacf6177bbd5ac8b34063e670739b8a268883","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_09b0ef89","line":189,"in_reply_to":"5a890539_554532b2","updated":"2014-12-03 15:59:35.000000000","message":"I looked at https://drive.google.com/file/d/0Bz_nyJF_YYGZZ05zaU9kb2Z4SE0/view which Deva had shared yesterday on IRC and i believe when there is some action state is there for discovery, there should be a state after action is completed. If action fails then also it requires the state to say that the requested action is failed.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_bb7e4019","line":189,"in_reply_to":"5a890539_554532b2","updated":"2014-12-03 16:47:45.000000000","message":"Victor, why is ZAPFAIL mentioned then? Because we want to make sure to note that it must be in maintenance mode? (I\u0027m fine deleting the ZAPFAIL description, for consistency.)","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"dcbc7dace2e22e1177e5bc5d98b166ae7e630e29","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  hardware-derived node properties to reflect the current state of the"},{"line_number":187,"context_line":"  hardware. We expect this state to get its data via the driver"},{"line_number":188,"context_line":"  introspection interface (reference to spec forthcoming). If"},{"line_number":189,"context_line":"  introspection fails, the node will transition to INSPECTFAIL."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_8ebb00c3","line":189,"in_reply_to":"5a890539_bb7e4019","updated":"2014-12-03 17:00:36.000000000","message":"Yes, that is why it is mentioned.  It is the only error state that we automatically put the node into maintenance mode, because going into ZAPFAIL generally cannot be recovered from without manual intervention -- the other -FAIL states can probably be recovered from in an automated fashion most of the time.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"353dc965f1242eb3a8b4c0ab608b0cb8ac42d55a","unresolved":false,"context_lines":[{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"},{"line_number":193,"context_line":"  being made AVAILABLE.  Tasks such as zeroing the drives and"},{"line_number":194,"context_line":"  validating firmware integrity should be performed here. Management"},{"line_number":195,"context_line":"  of CLEANING tasks should be handled in the same fashion as ZAPPING"},{"line_number":196,"context_line":"  tasks."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_3b1983d1","line":194,"updated":"2014-12-03 10:52:08.000000000","message":"Usually (I believe it\u0027s a good practice) in order to erase the disks in a RAID array, you break up the array first and then wipe the individual disks, to be confident, because that way you don\u0027t go through the abstraction layer of the RAID.\n\nNow I see that we are moving directly from CLEANING to AVAILABLE, if we break the array who is going to recreate it? Shouldn\u0027t ZAPPING be the next state after CLEANING?","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"fe7673f49e93a619a14a1e2d9f8ec189f8e316d6","unresolved":false,"context_lines":[{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"},{"line_number":193,"context_line":"  being made AVAILABLE.  Tasks such as zeroing the drives and"},{"line_number":194,"context_line":"  validating firmware integrity should be performed here. Management"},{"line_number":195,"context_line":"  of CLEANING tasks should be handled in the same fashion as ZAPPING"},{"line_number":196,"context_line":"  tasks."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_f50d3e90","line":194,"in_reply_to":"5a890539_0feb98a4","updated":"2014-12-03 14:54:19.000000000","message":"Done","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"54fb3323730ced8d61f48a6df5fbfd636083c5a0","unresolved":false,"context_lines":[{"line_number":191,"context_line":"CLEANING"},{"line_number":192,"context_line":"  Nodes in the CLEANING state are being scrubbed in preparation to"},{"line_number":193,"context_line":"  being made AVAILABLE.  Tasks such as zeroing the drives and"},{"line_number":194,"context_line":"  validating firmware integrity should be performed here. Management"},{"line_number":195,"context_line":"  of CLEANING tasks should be handled in the same fashion as ZAPPING"},{"line_number":196,"context_line":"  tasks."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_0feb98a4","line":194,"in_reply_to":"5a890539_3b1983d1","updated":"2014-12-03 14:10:24.000000000","message":"I moved this comment to L95 and forgot to remove this one, so please ignore it.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"913244633d3213b8f8e8a61823caf216cca4e857","unresolved":false,"context_lines":[{"line_number":221,"context_line":""},{"line_number":222,"context_line":"ACTIVE"},{"line_number":223,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":224,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":225,"context_line":"  them alone. Nodes in ACTIVE can transition to:"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_661d06be","line":224,"updated":"2014-12-04 00:44:41.000000000","message":"Ironic also perioridcally collects hardware sensors from ACTIVE nodes.  For drivers that can perform other out-of-band tasks (triggered by external API) that won\u0027t impact current state can also perform at this state, ,e.g, staging firmware settings for the next reboot).","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"0659eaa21ac0648e25e3162ffcf639014133c248","unresolved":false,"context_lines":[{"line_number":221,"context_line":""},{"line_number":222,"context_line":"ACTIVE"},{"line_number":223,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":224,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":225,"context_line":"  them alone. Nodes in ACTIVE can transition to:"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_d1573bff","line":224,"in_reply_to":"5a890539_661d06be","updated":"2014-12-04 16:39:31.000000000","message":"Good point about the hardware sensors information, although I would not stage firmware updates against an ACTIVE node -- I would push it back to MANAGED and ZAP it to do that.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":224,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":225,"context_line":"  them alone. Nodes in ACTIVE can transition to:"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"},{"line_number":228,"context_line":"  * DELETING via the delete API call, or"},{"line_number":229,"context_line":"  * AVAILABLE via the rebuild API call."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_9b7ee4e2","line":227,"updated":"2014-12-03 16:47:45.000000000","message":"\u0027RESCUE\u0027 -\u003e \u0027RESCUING\u0027 (unless we want to indicate the passive states). Whatever we decide, it should be consistent for the three points here.\n\nHmm, I see under \u0027RESCUE\u0027, that they transition to the passive states. If we want this to be passive too, then I guess they\u0027d be RESCUE, AVAILABLE, ACTIVE respectively.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1fbb92344a4982061ad9e56f5d58af0d04d40937","unresolved":false,"context_lines":[{"line_number":224,"context_line":"  check their power state on a regular basis, but will otherwise leave"},{"line_number":225,"context_line":"  them alone. Nodes in ACTIVE can transition to:"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"},{"line_number":228,"context_line":"  * DELETING via the delete API call, or"},{"line_number":229,"context_line":"  * AVAILABLE via the rebuild API call."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_44101000","line":227,"in_reply_to":"5a890539_9b7ee4e2","updated":"2014-12-03 20:29:17.000000000","message":"Will do.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"980bc357c82790e6815906f61b9d154c770977d9","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"},{"line_number":228,"context_line":"  * DELETING via the delete API call, or"},{"line_number":229,"context_line":"  * AVAILABLE via the rebuild API call."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"RESCUING"},{"line_number":232,"context_line":"  Nodes in RESCUING are being booted into a temporary operating"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_3b45f0b3","line":229,"updated":"2014-12-03 16:47:45.000000000","message":"I think \u0027AVAILABLE\u0027 -\u003e \u0027DEPLOYING\u0027 ?","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"1fbb92344a4982061ad9e56f5d58af0d04d40937","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"  * RESCUE via the rescue API call,"},{"line_number":228,"context_line":"  * DELETING via the delete API call, or"},{"line_number":229,"context_line":"  * AVAILABLE via the rebuild API call."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"RESCUING"},{"line_number":232,"context_line":"  Nodes in RESCUING are being booted into a temporary operating"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_44b570eb","line":229,"in_reply_to":"5a890539_3b45f0b3","updated":"2014-12-03 20:29:17.000000000","message":"You are correct, will fix.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"913244633d3213b8f8e8a61823caf216cca4e857","unresolved":false,"context_lines":[{"line_number":243,"context_line":""},{"line_number":244,"context_line":"UNRESCUING"},{"line_number":245,"context_line":"  Nodes in UNRESCUING are being transitioned back to ACTIVE from"},{"line_number":246,"context_line":"  RESCUE.  Ironic will unwind whatever it needed to do to get the node"},{"line_number":247,"context_line":"  into RESCUE"},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"DELETING"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_06136265","line":246,"updated":"2014-12-04 00:44:41.000000000","message":"\"Ironic will unwind whatever it needed to do to get the node into RESCUE\".   Shouldn\u0027t this go under RESCUE description? or did you mean to say to get out of RESCUE?","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"39d9e6590b589c176e2ddffa98932b6fdcf35bb3","unresolved":false,"context_lines":[{"line_number":243,"context_line":""},{"line_number":244,"context_line":"UNRESCUING"},{"line_number":245,"context_line":"  Nodes in UNRESCUING are being transitioned back to ACTIVE from"},{"line_number":246,"context_line":"  RESCUE.  Ironic will unwind whatever it needed to do to get the node"},{"line_number":247,"context_line":"  into RESCUE"},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"DELETING"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_65a245af","line":246,"in_reply_to":"5a890539_06136265","updated":"2014-12-04 14:54:41.000000000","message":"UNRESCUING is a different (and active) state from RESCU*. (The diagram above may help.)","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"913244633d3213b8f8e8a61823caf216cca4e857","unresolved":false,"context_lines":[{"line_number":249,"context_line":"DELETING"},{"line_number":250,"context_line":"  Nodes in DELETING state are being torn down from running an active"},{"line_number":251,"context_line":"  workload.  In DELETING, Ironic should tear down or remove any"},{"line_number":252,"context_line":"  configuration or resources it added in DEPLOYING."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Alternatives"},{"line_number":255,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_a906dfcb","line":252,"updated":"2014-12-04 00:44:41.000000000","message":"Is zapping part of the tear-down process or are  zapping and decomm seperate now?","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"39d9e6590b589c176e2ddffa98932b6fdcf35bb3","unresolved":false,"context_lines":[{"line_number":249,"context_line":"DELETING"},{"line_number":250,"context_line":"  Nodes in DELETING state are being torn down from running an active"},{"line_number":251,"context_line":"  workload.  In DELETING, Ironic should tear down or remove any"},{"line_number":252,"context_line":"  configuration or resources it added in DEPLOYING."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Alternatives"},{"line_number":255,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_85081192","line":252,"in_reply_to":"5a890539_a906dfcb","updated":"2014-12-04 14:54:41.000000000","message":"I think it depends on your definition (the tasks involved) of zapping \u0026 decomm. Take a look at the diagram above and the comments above (L95) related to CLEAN* and ZAP*. Hopefully that will answer your question.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":10202,"name":"Wan-yen Hsu","email":"wanyenhsu@gmail.com"},"change_message_id":"bf657b288c75bb4eb403cbf469e205f78521ed61","unresolved":false,"context_lines":[{"line_number":250,"context_line":"  Nodes in DELETING state are being torn down from running an active"},{"line_number":251,"context_line":"  workload.  In DELETING, Ironic should tear down or remove any"},{"line_number":252,"context_line":"  configuration or resources it added in DEPLOYING."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Alternatives"},{"line_number":255,"context_line":"------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_627329e7","line":253,"updated":"2014-12-04 06:41:36.000000000","message":"What is the target state for DELETING?   Potentially,  it can go into zapping-\u003ezapped-\u003eavailalbe.  I didn\u0027t see the state diagram show that though.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"39d9e6590b589c176e2ddffa98932b6fdcf35bb3","unresolved":false,"context_lines":[{"line_number":250,"context_line":"  Nodes in DELETING state are being torn down from running an active"},{"line_number":251,"context_line":"  workload.  In DELETING, Ironic should tear down or remove any"},{"line_number":252,"context_line":"  configuration or resources it added in DEPLOYING."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Alternatives"},{"line_number":255,"context_line":"------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a890539_45a2a93f","line":253,"in_reply_to":"5a890539_627329e7","updated":"2014-12-04 14:54:41.000000000","message":"The diagram shows [DELET*/AVAILABLE] \u003d\u003d so the target state is AVAILABLE. It does NOT go via zapping though. It goes from DELETING to CLEANING to available.\n\nIf you need/want to zap, you\u0027d need to explicitly send two API requests, to get to MANAGED and to ZAPPING.","commit_id":"cd77c7deaddfc5c118552a3e45b5d796b2c6e796"},{"author":{"_account_id":7623,"name":"Erwan Velu","email":"erwan@enovance.com","username":"erwan"},"change_message_id":"dbc5d356fbb68028a2d6bc23a48df13f6206d10d","unresolved":false,"context_lines":[{"line_number":209,"context_line":"  as ZAPPING tasks."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"  No matter what tasks are performed during CLEANING, the apparent"},{"line_number":212,"context_line":"  configuration of the system must not change.  For instance, if you"},{"line_number":213,"context_line":"  tear down a set of RAID volumes to securely erase each physical disk"},{"line_number":214,"context_line":"  seperately, you must rebuild the RAID volumes you tore down."},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_ba6a5aeb","line":212,"updated":"2014-12-05 17:11:21.000000000","message":"That means the identifier of the exisiting RAID array changed (like uuids) and prevents to keep the tracking of which RAID array was built for what purpose.\n\nThat why I do think, the creation of the RAID arrays should be performed after the clean state was executed.\n\nClean should clean the existing and let ZAP or similar task build the RAIDs one for all.\n\nThat idea of rebuild already created RAIDs volumes breaks the consistency of UUIDs amongst time.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"e0cd0d4a0bdc46f45a63c75e2969c4ab976591e2","unresolved":false,"context_lines":[{"line_number":209,"context_line":"  as ZAPPING tasks."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"  No matter what tasks are performed during CLEANING, the apparent"},{"line_number":212,"context_line":"  configuration of the system must not change.  For instance, if you"},{"line_number":213,"context_line":"  tear down a set of RAID volumes to securely erase each physical disk"},{"line_number":214,"context_line":"  seperately, you must rebuild the RAID volumes you tore down."},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_5d8df0d2","line":212,"in_reply_to":"5a890539_ba6a5aeb","updated":"2014-12-05 17:32:27.000000000","message":"In the case of md  and dm based softraid, name the volume.  This has the advantage that it also works with hardware RAID controllers that support DDF but that do not expose (or even have) a volume UUID.\n\nProblem solved using the tools intended to solve it!","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"8ef055352bb39c22aea222958de82af9d3829fb2","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."},{"line_number":230,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":231,"context_line":"    that may be required by additional subsystems."},{"line_number":232,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_53a89c8c","line":229,"updated":"2014-12-05 04:46:00.000000000","message":"Laying down a filesystem isn\u0027t necessarily short-lived. i.e. dependent on fs size.  A large disk format might be measured in hours.\n\nIf the key here point for this state is short-lived tasks, would it be better to do fs ops in CLEANING or similar?","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."},{"line_number":230,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":231,"context_line":"    that may be required by additional subsystems."},{"line_number":232,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_8715474e","line":229,"in_reply_to":"5a890539_53a89c8c","updated":"2014-12-05 16:57:31.000000000","message":"My preferred solution is to suggest not using ext3 anymore. ext4 and xfs are stable, fast, and supported on everything that is not ancient.  If you are stuck on something in the RHEL/Centos 5 era then my condolences.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a3363725ba2abea5f18ae4a67ae5ee671e3d5ac6","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."},{"line_number":230,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":231,"context_line":"    that may be required by additional subsystems."},{"line_number":232,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_9579f684","line":229,"in_reply_to":"5a890539_53a89c8c","updated":"2014-12-05 15:11:27.000000000","message":"You can\u0027t know what the filesystem will look like until deploy time. :(","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"00c3865bdbfe9d82cac0d5e723e1da836bd9b778","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."},{"line_number":230,"context_line":"  * Creating any additional resources (node-specific network config, etc.)"},{"line_number":231,"context_line":"    that may be required by additional subsystems."},{"line_number":232,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_4a03620f","line":229,"in_reply_to":"5a890539_8715474e","updated":"2014-12-08 16:12:54.000000000","message":"I agree with Jim, Ironic can not know about the workload file system.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"1735eb3fd5c394678849b6f04d56f66242d161a3","unresolved":false,"context_lines":[{"line_number":233,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_7dc46c0e","line":236,"updated":"2014-12-05 17:28:31.000000000","message":"++ to what Jim said.\n\nI\u0027ll add to \"this isn\u0027t always possible\" by saying \"this is never possible\" -- Ironic is not in the business of knowing anything about the user\u0027s payload which Ironic deployed to the machine.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":13362,"name":"Tan Lin","email":"lin.tan@intel.com","username":"zero"},"change_message_id":"26ee6f9a7baa61a698232f680f8c0fe9cf4840ff","unresolved":false,"context_lines":[{"line_number":233,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_15835d56","line":236,"updated":"2014-12-05 02:35:56.000000000","message":"Is it possible to use power state as a signal to confirm the transition from Deployed to Active is success? But power state is not good enough. For example, it will boot up but block in the pxe booting. \nAnother possible signal is a post-processing script.\nAs all cloud images should have cloud-init, we can pass a script as metadata to send a signal to ironic, like what we did in original baremetal ramdisk.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":233,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_dadf2639","line":236,"in_reply_to":"5a890539_15835d56","updated":"2014-12-05 16:57:31.000000000","message":"Deployed is a momentary state -- the only way the transition from deployed to active could fail is if the conductor managing the transition exploded or the database died before the relevant transaction committed.\n\nAs far as power signals go, this state machine does not model power state transitions -- power control has its own state machine and set of error handlers.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a3363725ba2abea5f18ae4a67ae5ee671e3d5ac6","unresolved":false,"context_lines":[{"line_number":233,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_55cdceb9","line":236,"in_reply_to":"5a890539_15835d56","updated":"2014-12-05 15:11:27.000000000","message":"This isn\u0027t always possible. Ironic should not be in the business of running code on a tenant machine. If an operator decides to do this in their images, that is their decision.\n\nThis also involves exposing the Ironic API to tenant machines, which seems pretty bad. :)","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":13362,"name":"Tan Lin","email":"lin.tan@intel.com","username":"zero"},"change_message_id":"902922aef852c8f3164c36895ad996a1ca2b34a9","unresolved":false,"context_lines":[{"line_number":233,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_b3b8b7c8","line":236,"in_reply_to":"5a890539_7dc46c0e","updated":"2014-12-06 06:05:35.000000000","message":"I understand \"this is never possible\". I may miss something. But I am thinking the whole deployment process. Right now, once deploy-done, the state of nova instance will change to active as same as ironic node. I assume this will be the same in the future.\nSo from user point of view, he sees the instance state is become active on horizon, he believes the whole deployment is done and he can access the instance, which is possible not.\nI think we need to consider the case, maybe out of ironic.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"abfbfcd2091a59d23f2af554c41429cb2a661578","unresolved":false,"context_lines":[{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"},{"line_number":240,"context_line":"  ACTIVE can transition to:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_84a56104","line":237,"updated":"2014-12-05 00:14:08.000000000","message":"Nit: s/will/may/ but I really don\u0027t care","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":234,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"ACTIVE"},{"line_number":237,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic will"},{"line_number":238,"context_line":"  collect out-of-band sensor information (including power state)"},{"line_number":239,"context_line":"  on a regular basis, but will otherwise leave them alone. Nodes in"},{"line_number":240,"context_line":"  ACTIVE can transition to:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_df68148a","line":237,"in_reply_to":"5a890539_84a56104","updated":"2014-12-05 16:57:31.000000000","message":"Will fix.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"00c3865bdbfe9d82cac0d5e723e1da836bd9b778","unresolved":false,"context_lines":[{"line_number":246,"context_line":""},{"line_number":247,"context_line":"RESCUING"},{"line_number":248,"context_line":"  Nodes in RESCUING are being booted into a temporary operating"},{"line_number":249,"context_line":"  environment for troubleshooting or maintenance related reasons."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"RESCUE"},{"line_number":252,"context_line":"  RESCUE exists to allow Ironic to be aware of a node that would be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_70764c40","line":249,"updated":"2014-12-08 16:12:54.000000000","message":"seems logical but we may want to point out that Ironic should not change any data on the disks to boot up in the rescue image.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"00c3865bdbfe9d82cac0d5e723e1da836bd9b778","unresolved":false,"context_lines":[{"line_number":259,"context_line":""},{"line_number":260,"context_line":"UNRESCUING"},{"line_number":261,"context_line":"  Nodes in UNRESCUING are being transitioned back to ACTIVE from"},{"line_number":262,"context_line":"  RESCUE.  Ironic will unwind whatever it needed to do to get the node"},{"line_number":263,"context_line":"  into RESCUE"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"DELETING"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_904bb8af","line":262,"updated":"2014-12-08 16:12:54.000000000","message":"I feel that the only thing  Ironic should have to do here is reboot in to the users image.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":275,"context_line":"Data model impact"},{"line_number":276,"context_line":"-----------------"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Probably."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"REST API impact"},{"line_number":281,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_f3727148","line":278,"updated":"2014-12-04 22:33:31.000000000","message":"Notable data model changes:\n- today\u0027s \"NOSTATE\" is represented by NULL value in the database. This will require a DB migration to change to AVAILABLE, and some special handling in the API during the migration period.\n- additional states need to be added to ironic/common/states.py, but should not require database migrations.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":275,"context_line":"Data model impact"},{"line_number":276,"context_line":"-----------------"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Probably."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"REST API impact"},{"line_number":281,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_1ae1aefc","line":278,"in_reply_to":"5a890539_f3727148","updated":"2014-12-05 16:57:31.000000000","message":"Will add.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":280,"context_line":"REST API impact"},{"line_number":281,"context_line":"---------------"},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"Definitely."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"RPC API impact"},{"line_number":286,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_136e1d64","line":283,"updated":"2014-12-04 22:33:31.000000000","message":"Backwards-compatibility can be maintained with respect to REST clients driving the API changes because the only three verbs which are in use today are preserved in the new model. That being \"active\", \"rebuild\", and \"delete\".\n\nHowever, older clients will be very confused when talking to a newer service and finding nodes in states they do not understand...","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":280,"context_line":"REST API impact"},{"line_number":281,"context_line":"---------------"},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"Definitely."},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"RPC API impact"},{"line_number":286,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_3aee6aee","line":283,"in_reply_to":"5a890539_136e1d64","updated":"2014-12-05 16:57:31.000000000","message":"Will add.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":285,"context_line":"RPC API impact"},{"line_number":286,"context_line":"--------------"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Yup."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Driver API impact"},{"line_number":291,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_33907942","line":288,"updated":"2014-12-04 22:33:31.000000000","message":"Maybe not directly. The existing RPC calls shouldn\u0027t be changing, I think.\n\nWhile a lot of new functionality is desribed by these states (eg, ZAPPING, INSPECTING, etc), each of those will require a separate spec to implement, and that is where I expect the majority of new RPC (and REST API) changes to be impemented.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":285,"context_line":"RPC API impact"},{"line_number":286,"context_line":"--------------"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Yup."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Driver API impact"},{"line_number":291,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_5aeb36dc","line":288,"in_reply_to":"5a890539_33907942","updated":"2014-12-05 16:57:31.000000000","message":"Will add.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":290,"context_line":"Driver API impact"},{"line_number":291,"context_line":"-----------------"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"Yes."},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"Nova driver impact"},{"line_number":296,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_5393454e","line":293,"updated":"2014-12-04 22:33:31.000000000","message":"Oh heck yes. There\u0027s a lot of refactoring around what parts of code can influence the state of a node.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":295,"context_line":"Nova driver impact"},{"line_number":296,"context_line":"------------------"},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"NOSTATE has been renamed to AVAILABLE."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Security impact"},{"line_number":301,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_7396813f","line":298,"updated":"2014-12-04 22:33:31.000000000","message":"Yup. This\u0027ll require some glue code in our API to smooth over, and some thought about the upgrade path for users.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"75b9cf71a3b5b37c2cdfb2e50e970f24d9e06442","unresolved":false,"context_lines":[{"line_number":295,"context_line":"Nova driver impact"},{"line_number":296,"context_line":"------------------"},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"NOSTATE has been renamed to AVAILABLE."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Security impact"},{"line_number":301,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_dab646f9","line":298,"in_reply_to":"5a890539_7396813f","updated":"2014-12-05 16:57:31.000000000","message":"Will add.","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"0c5435e6fdcb879c61a6035786fa7cb97145b351","unresolved":false,"context_lines":[{"line_number":333,"context_line":"Assignee(s)"},{"line_number":334,"context_line":"-----------"},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"None yet."},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"Work Items"},{"line_number":339,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a890539_93992d6f","line":336,"updated":"2014-12-04 22:33:31.000000000","message":"I\u0027ve got a series of patches migrating the current code to use a FSM:\n\nhttps://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:states,n,z","commit_id":"305c70fbce7ac88d3cb40ec1eec6bcca9f3c838b"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* We also need to let external orchestration systems hook into parts of the"},{"line_number":39,"context_line":"  state machine for each node to let them manage parts of the node life cycle"},{"line_number":40,"context_line":"  without having to import that functionality into Ironic."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Proposed change"},{"line_number":43,"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":11,"id":"3a961159_7cc53a5a","line":40,"updated":"2014-12-08 23:05:46.000000000","message":"The first three points have been addressed by this spec, but has this one been addressed?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"5ec0ccca2f409e8f69b13c0582dce04eb4dc2773","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* We also need to let external orchestration systems hook into parts of the"},{"line_number":39,"context_line":"  state machine for each node to let them manage parts of the node life cycle"},{"line_number":40,"context_line":"  without having to import that functionality into Ironic."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Proposed change"},{"line_number":43,"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":11,"id":"3a961159_8193454e","line":40,"in_reply_to":"3a961159_2c21ba9f","updated":"2014-12-09 15:50:16.000000000","message":"Will add a note specifying that implementation details will be covered in a different spec.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"0d4ed4eb9218bbaf5aa3e3f7bd76ab50caed343e","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* We also need to let external orchestration systems hook into parts of the"},{"line_number":39,"context_line":"  state machine for each node to let them manage parts of the node life cycle"},{"line_number":40,"context_line":"  without having to import that functionality into Ironic."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Proposed change"},{"line_number":43,"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":11,"id":"3a961159_2c21ba9f","line":40,"in_reply_to":"3a961159_7cc53a5a","updated":"2014-12-09 06:09:06.000000000","message":"We probably need something to address this - eve if it\u0027s a \"this will be covered in a subsequent spec\", or perhaps just removed entirely?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":89,"context_line":"                  +        |  | | |           +"},{"line_number":90,"context_line":"         [ZAP*/MANAGED]\u003c---+  | | +-\u003e[INSPECT*/MANAGED]"},{"line_number":91,"context_line":"                              | |"},{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_42425811","line":92,"updated":"2014-12-08 23:05:46.000000000","message":"What\u0027s the rationale for \u0027provide\u0027\u0027, vs eg \u0027clean\u0027?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"5ec0ccca2f409e8f69b13c0582dce04eb4dc2773","unresolved":false,"context_lines":[{"line_number":89,"context_line":"                  +        |  | | |           +"},{"line_number":90,"context_line":"         [ZAP*/MANAGED]\u003c---+  | | +-\u003e[INSPECT*/MANAGED]"},{"line_number":91,"context_line":"                              | |"},{"line_number":92,"context_line":"                     R:provide| +----------+"},{"line_number":93,"context_line":"                      +-------+   R:manage |"},{"line_number":94,"context_line":"                      v                    +"},{"line_number":95,"context_line":"             [CLEAN*/AVAILABLE]+-------\u003eAVAILABLE"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_612c9903","line":92,"in_reply_to":"3a961159_42425811","updated":"2014-12-09 15:50:16.000000000","message":"Because the end result of the API call is a node that is available for Nova or whoever.  Cleaning is an essential part of the process, but it is not the goal.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":203,"context_line":"    described in node.properties."},{"line_number":204,"context_line":"  * Booting to a `long running deploy ramdisk"},{"line_number":205,"context_line":"    \u003chttps://review.openstack.org/#/c/102405/\u003e`_, if you want the"},{"line_number":206,"context_line":"    machine to stay on while in AVAILABLE."},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"  Management of CLEANING tasks should be handled in the same fashion"},{"line_number":209,"context_line":"  as ZAPPING tasks."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_a26f7c91","line":206,"updated":"2014-12-08 23:05:46.000000000","message":"Do you mean, so it\u0027ll be powered on when it becomes AVAILABLE?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"5ec0ccca2f409e8f69b13c0582dce04eb4dc2773","unresolved":false,"context_lines":[{"line_number":203,"context_line":"    described in node.properties."},{"line_number":204,"context_line":"  * Booting to a `long running deploy ramdisk"},{"line_number":205,"context_line":"    \u003chttps://review.openstack.org/#/c/102405/\u003e`_, if you want the"},{"line_number":206,"context_line":"    machine to stay on while in AVAILABLE."},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"  Management of CLEANING tasks should be handled in the same fashion"},{"line_number":209,"context_line":"  as ZAPPING tasks."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_e1540956","line":206,"in_reply_to":"3a961159_a26f7c91","updated":"2014-12-09 15:50:16.000000000","message":"sorta -- my understanding is that usually nodes in AVAILABLE would be sitting there powered off until something grabbed it.  The long-running deploy ramdisk mechanism would leave the node powered on.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"0d4ed4eb9218bbaf5aa3e3f7bd76ab50caed343e","unresolved":false,"context_lines":[{"line_number":223,"context_line":"DEPLOYING"},{"line_number":224,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."},{"line_number":225,"context_line":"  This should mainly consist of running a series of short-lived tasks,"},{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_6c966296","line":226,"updated":"2014-12-09 06:09:06.000000000","message":"I agree with all the replies to my query on revision 10 (thanks :) - however, you *cannot* say that laying down a filesystem will be short-lived. If we\u0027re setting the expectation that this state will be quick I think we\u0027re being disingenuous.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"5ec0ccca2f409e8f69b13c0582dce04eb4dc2773","unresolved":false,"context_lines":[{"line_number":223,"context_line":"DEPLOYING"},{"line_number":224,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."},{"line_number":225,"context_line":"  This should mainly consist of running a series of short-lived tasks,"},{"line_number":226,"context_line":"  such as:"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"  * Setting appropriate BIOS configurations"},{"line_number":229,"context_line":"  * Partitioning drives and laying down file systems."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_24353fda","line":226,"in_reply_to":"3a961159_6c966296","updated":"2014-12-09 15:50:16.000000000","message":"That is why the word \"mainly\" is in the spec description.  In the end, though, the choice of filesystem is up to the tenant.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":285,"context_line":"---------------"},{"line_number":286,"context_line":""},{"line_number":287,"context_line":"The API will remain backwards compatible with the active, rebuild, and"},{"line_number":288,"context_line":"delete verbs.  We will add new verbs to handle the new state transitions."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Since we are adding new states, older API clients may behave"},{"line_number":291,"context_line":"unexpectedly when they encounter a node in a state they do not understand."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_c23488e0","line":288,"updated":"2014-12-08 23:05:46.000000000","message":"Should we start itemizing them? Based on the diagram, we have validate, zap, inspect, provide (I don\u0027t like provide), manage, rescue, unrescue.\n\nWe have \u0027GET /v1/nodes/validate\u0027 but it isn\u0027t the same validate here.\n\n\u0027PUT /v1/nodes/(node_uuid)/states/provision\u0027 is used to specify the target (provision) state, and is used to get to active, rebuild, and delete. Does it make sense to extend this to handle other (new) states? Or add a new API eg \u0027PUT /v1/nodes/(node_uuid)/action\u0027","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"5ec0ccca2f409e8f69b13c0582dce04eb4dc2773","unresolved":false,"context_lines":[{"line_number":285,"context_line":"---------------"},{"line_number":286,"context_line":""},{"line_number":287,"context_line":"The API will remain backwards compatible with the active, rebuild, and"},{"line_number":288,"context_line":"delete verbs.  We will add new verbs to handle the new state transitions."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Since we are adding new states, older API clients may behave"},{"line_number":291,"context_line":"unexpectedly when they encounter a node in a state they do not understand."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_0464c3e3","line":288,"in_reply_to":"3a961159_c23488e0","updated":"2014-12-09 15:50:16.000000000","message":"I will itemize the verbs and their impact on the state machine.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":288,"context_line":"delete verbs.  We will add new verbs to handle the new state transitions."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Since we are adding new states, older API clients may behave"},{"line_number":291,"context_line":"unexpectedly when they encounter a node in a state they do not understand."},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"RPC API impact"},{"line_number":294,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_7caa9a71","line":291,"updated":"2014-12-08 23:05:46.000000000","message":"It isn\u0027t time for a V2, is it?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"52a8523335b8b520415884fe80f8faf33eebefc9","unresolved":false,"context_lines":[{"line_number":333,"context_line":"Other deployer impact"},{"line_number":334,"context_line":"---------------------"},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"Hopefully not."},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"Developer impact"},{"line_number":339,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_f6ca34a0","line":336,"updated":"2014-12-08 16:29:05.000000000","message":"A change worth noting here: that enrolled nodes will need to be manually  transitioned to AVAILABLE, before they can be scheduled.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d93831ce62d949239e07ad23d9188dc78185d754","unresolved":false,"context_lines":[{"line_number":333,"context_line":"Other deployer impact"},{"line_number":334,"context_line":"---------------------"},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"Hopefully not."},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"Developer impact"},{"line_number":339,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_045b0a88","line":336,"updated":"2014-12-08 17:20:15.000000000","message":"Good point, Chris","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":368,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":369,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_e2e4243d","line":371,"updated":"2014-12-08 23:05:46.000000000","message":"We want (or must) be backwards compatible for how long?","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"e80920b8f485298033fb66917aad295069783fa5","unresolved":false,"context_lines":[{"line_number":374,"context_line":"Documentation Impact"},{"line_number":375,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"The new state machine code will need to be thoroughly documented."},{"line_number":378,"context_line":""},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_e28d047d","line":377,"updated":"2014-12-08 23:05:46.000000000","message":"In particular, the API requests that need to be explicitly issued to cause the node to change states.","commit_id":"c133cc13bd8cf8603ca27c913015ff604d752dda"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This blueprint suggests reworking the Ironic provisioning state machine"},{"line_number":14,"context_line":"to fix some current shortcomings and to make it easier for drivers and"},{"line_number":15,"context_line":"external orchestration agents to manage nodes in Ironic.  Please note"},{"line_number":16,"context_line":"that this blueprint describes the functionality we intend the new"},{"line_number":17,"context_line":"state machine to have.  Actual implementation of this spec, including"},{"line_number":18,"context_line":"detailed upgrade paths and technical arcana will be handled by other"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_7aea7e10","line":15,"updated":"2014-12-09 16:54:19.000000000","message":"Thanks for adding this note. If you do another revision, it might be good to put this in a new paragraph with a big/bold NOTE. Or not ;)","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This blueprint suggests reworking the Ironic provisioning state machine"},{"line_number":14,"context_line":"to fix some current shortcomings and to make it easier for drivers and"},{"line_number":15,"context_line":"external orchestration agents to manage nodes in Ironic.  Please note"},{"line_number":16,"context_line":"that this blueprint describes the functionality we intend the new"},{"line_number":17,"context_line":"state machine to have.  Actual implementation of this spec, including"},{"line_number":18,"context_line":"detailed upgrade paths and technical arcana will be handled by other"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_b56f97c4","line":15,"in_reply_to":"3a961159_7aea7e10","updated":"2014-12-09 17:01:18.000000000","message":"Will do.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":227,"context_line":""},{"line_number":228,"context_line":"DEPLOYING"},{"line_number":229,"context_line":"  Nodes in DEPLOYING are being actively prepared to run a workload on them."},{"line_number":230,"context_line":"  This should mainly consist of running a series of short-lived tasks,"},{"line_number":231,"context_line":"  such as:"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"  * Setting appropriate BIOS configurations"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_3a77163c","line":230,"updated":"2014-12-09 16:54:19.000000000","message":"i don\u0027t know if this helps Michael or not, but how about \u0027It is recommended that this consists of running a series of short-lived tasks, that might include:\u0027","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":236,"context_line":"    that may be required by additional subsystems."},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":239,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"ACTIVE"},{"line_number":242,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic may"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_5aedc2ee","line":239,"updated":"2014-12-09 16:54:19.000000000","message":"Do you want it to say \u0027spec hopefully forthcoming?\u0027 or something like \u0027addressed in a separate spec\u0027?","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":236,"context_line":"    that may be required by additional subsystems."},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"  Tasks for DEPLOYING should be handled in a manner similar to how"},{"line_number":239,"context_line":"  they are handled for ZAPPING (spec hopefully forthcoming?)."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"ACTIVE"},{"line_number":242,"context_line":"  Nodes in ACTIVE have a workload running on them.  Ironic may"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_759c4fc1","line":239,"in_reply_to":"3a961159_5aedc2ee","updated":"2014-12-09 17:01:18.000000000","message":"Will change","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":322,"context_line":"Unless otherwise required for backwards compatibility, the verbs must"},{"line_number":323,"context_line":"be called when the node is in the Initial State, and Ironic will"},{"line_number":324,"context_line":"perform all actions and transitions needed to move through the"},{"line_number":325,"context_line":"Intermediae States to the End State."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"Since we are adding new states, older API clients may behave"},{"line_number":328,"context_line":"unexpectedly when they encounter a node in a state they do not understand."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_7ab7ded8","line":325,"updated":"2014-12-09 16:54:19.000000000","message":"typo (if you care): intermediate","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":322,"context_line":"Unless otherwise required for backwards compatibility, the verbs must"},{"line_number":323,"context_line":"be called when the node is in the Initial State, and Ironic will"},{"line_number":324,"context_line":"perform all actions and transitions needed to move through the"},{"line_number":325,"context_line":"Intermediae States to the End State."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"Since we are adding new states, older API clients may behave"},{"line_number":328,"context_line":"unexpectedly when they encounter a node in a state they do not understand."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_959ffbb3","line":325,"in_reply_to":"3a961159_7ab7ded8","updated":"2014-12-09 17:01:18.000000000","message":"Will fix.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0f1a13666dea9955ace2ca7f9020a5d20b430ad7","unresolved":false,"context_lines":[{"line_number":370,"context_line":"Other deployer impact"},{"line_number":371,"context_line":"---------------------"},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":374,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":"Developer impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_3f59c85a","line":373,"updated":"2014-12-09 16:32:08.000000000","message":"Nit, if another patchset is pushed: s/MANGED/MANAGED","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":370,"context_line":"Other deployer impact"},{"line_number":371,"context_line":"---------------------"},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":374,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":"Developer impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_d5a983e0","line":373,"in_reply_to":"3a961159_3f59c85a","updated":"2014-12-09 17:01:18.000000000","message":"Will fix.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":371,"context_line":"---------------------"},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":374,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":"Developer impact"},{"line_number":377,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_3a4f16bf","line":374,"updated":"2014-12-09 16:54:19.000000000","message":"Do we also want to mention that a deployer also needs to issue a validate request to get from ENROLL to MANAGED?","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":371,"context_line":"---------------------"},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":374,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":"Developer impact"},{"line_number":377,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_35bac723","line":374,"in_reply_to":"3a961159_3a4f16bf","updated":"2014-12-09 17:01:18.000000000","message":"Will add to verb table and mention that here.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":376,"context_line":"Developer impact"},{"line_number":377,"context_line":"----------------"},{"line_number":378,"context_line":""},{"line_number":379,"context_line":"This exists to get developer feedback and impact assessment."},{"line_number":380,"context_line":""},{"line_number":381,"context_line":"Implementation"},{"line_number":382,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_bad226d0","line":379,"updated":"2014-12-09 16:54:19.000000000","message":"Maybe this should be changed?","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":376,"context_line":"Developer impact"},{"line_number":377,"context_line":"----------------"},{"line_number":378,"context_line":""},{"line_number":379,"context_line":"This exists to get developer feedback and impact assessment."},{"line_number":380,"context_line":""},{"line_number":381,"context_line":"Implementation"},{"line_number":382,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_b5f4f7f2","line":379,"in_reply_to":"3a961159_bad226d0","updated":"2014-12-09 17:01:18.000000000","message":"I suppose so, in light of all the feedback I have gotten. :)","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Work Items"},{"line_number":390,"context_line":"----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"Lots of discussion in comments to be done."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"Dependencies"},{"line_number":395,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_1ad7bac0","line":392,"updated":"2014-12-09 16:54:19.000000000","message":"and maybe this should be changed to -- lots of specs to deal with minor (ha) implementation details.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Work Items"},{"line_number":390,"context_line":"----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"Lots of discussion in comments to be done."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"Dependencies"},{"line_number":395,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_95d45b48","line":392,"in_reply_to":"3a961159_1ad7bac0","updated":"2014-12-09 17:01:18.000000000","message":"Will change.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":400,"context_line":"Testing"},{"line_number":401,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":402,"context_line":""},{"line_number":403,"context_line":"We have a lot of talking to do about this."},{"line_number":404,"context_line":""},{"line_number":405,"context_line":""},{"line_number":406,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_7aefde87","line":403,"updated":"2014-12-09 16:54:19.000000000","message":"see specs for implementation/testing details.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":400,"context_line":"Testing"},{"line_number":401,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":402,"context_line":""},{"line_number":403,"context_line":"We have a lot of talking to do about this."},{"line_number":404,"context_line":""},{"line_number":405,"context_line":""},{"line_number":406,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_f5c4bf93","line":403,"in_reply_to":"3a961159_7aefde87","updated":"2014-12-09 17:01:18.000000000","message":"Will change.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"44e033871007b3fc6a486c0b2b4c20dc85cd5f53","unresolved":false,"context_lines":[{"line_number":406,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":407,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_bae94682","line":409,"updated":"2014-12-09 16:54:19.000000000","message":"see specs ..., not discussed here.","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"4c0c9c2edf4187e0fd276562914f346f78de53a2","unresolved":false,"context_lines":[{"line_number":406,"context_line":"Upgrades and Backwards Compatibility"},{"line_number":407,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"Plenty of backwards compatibility issues to be discussed."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_15c06b7b","line":409,"in_reply_to":"3a961159_bae94682","updated":"2014-12-09 17:01:18.000000000","message":"Will change","commit_id":"c7dd5d00aadb6f8912d7d4fd2fe80bc6293e05c9"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"28bc4a6c10b9d43c5606ebf1b27012aca333c7e2","unresolved":false,"context_lines":[{"line_number":264,"context_line":"  * ACTIVE (through UNRESCUEING) via the unrescue API call, or"},{"line_number":265,"context_line":"  * AVAILABLE (through DELETING and CLEANING) via the delete API call."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"UNRESCUEING"},{"line_number":268,"context_line":"  Nodes in UNRESCUEING are being transitioned back to ACTIVE from"},{"line_number":269,"context_line":"  RESCUE.  Ironic will unwind whatever it needed to do to get the node"},{"line_number":270,"context_line":"  into RESCUE"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_10c6b949","line":267,"updated":"2014-12-09 17:42:30.000000000","message":"is it \u0027unrescueing\u0027 but \u0027rescuing\u0027?","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c2976a2ad61a7d698ccf4f7cfb8f3984be76d98c","unresolved":false,"context_lines":[{"line_number":264,"context_line":"  * ACTIVE (through UNRESCUEING) via the unrescue API call, or"},{"line_number":265,"context_line":"  * AVAILABLE (through DELETING and CLEANING) via the delete API call."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"UNRESCUEING"},{"line_number":268,"context_line":"  Nodes in UNRESCUEING are being transitioned back to ACTIVE from"},{"line_number":269,"context_line":"  RESCUE.  Ironic will unwind whatever it needed to do to get the node"},{"line_number":270,"context_line":"  into RESCUE"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_d0ec3192","line":267,"in_reply_to":"3a961159_10c6b949","updated":"2014-12-09 17:53:33.000000000","message":"NM, google and aspell disagree.  rescuing and unrescuing are correct.","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"28bc4a6c10b9d43c5606ebf1b27012aca333c7e2","unresolved":false,"context_lines":[{"line_number":378,"context_line":""},{"line_number":379,"context_line":"Nodes will not automatically transition from ENROLL to MANAGED."},{"line_number":380,"context_line":"Deployers must assign drivers and add credentials to the node and then"},{"line_number":381,"context_line":"call the validate API to before Ironic can manage the node."},{"line_number":382,"context_line":""},{"line_number":383,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":384,"context_line":"deployers will need to do that via the API before nodes can be scheduled."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_f03f6d23","line":381,"updated":"2014-12-09 17:42:30.000000000","message":"\u0027to before\u0027 -\u003e \u0027before\u0027","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c2976a2ad61a7d698ccf4f7cfb8f3984be76d98c","unresolved":false,"context_lines":[{"line_number":378,"context_line":""},{"line_number":379,"context_line":"Nodes will not automatically transition from ENROLL to MANAGED."},{"line_number":380,"context_line":"Deployers must assign drivers and add credentials to the node and then"},{"line_number":381,"context_line":"call the validate API to before Ironic can manage the node."},{"line_number":382,"context_line":""},{"line_number":383,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":384,"context_line":"deployers will need to do that via the API before nodes can be scheduled."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_30301501","line":381,"in_reply_to":"3a961159_f03f6d23","updated":"2014-12-09 17:53:33.000000000","message":"Done","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"28bc4a6c10b9d43c5606ebf1b27012aca333c7e2","unresolved":false,"context_lines":[{"line_number":380,"context_line":"Deployers must assign drivers and add credentials to the node and then"},{"line_number":381,"context_line":"call the validate API to before Ironic can manage the node."},{"line_number":382,"context_line":""},{"line_number":383,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":384,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":385,"context_line":""},{"line_number":386,"context_line":"Developer impact"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_304ad5c5","line":383,"updated":"2014-12-09 17:42:30.000000000","message":"there\u0027s that typo that Jim mentioned. s/MANGED/MANAGED/","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c2976a2ad61a7d698ccf4f7cfb8f3984be76d98c","unresolved":false,"context_lines":[{"line_number":380,"context_line":"Deployers must assign drivers and add credentials to the node and then"},{"line_number":381,"context_line":"call the validate API to before Ironic can manage the node."},{"line_number":382,"context_line":""},{"line_number":383,"context_line":"Nodes will not automatically transition from MANGED to AVAILABLE,"},{"line_number":384,"context_line":"deployers will need to do that via the API before nodes can be scheduled."},{"line_number":385,"context_line":""},{"line_number":386,"context_line":"Developer impact"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_502be193","line":383,"in_reply_to":"3a961159_304ad5c5","updated":"2014-12-09 17:53:33.000000000","message":"Done","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"28bc4a6c10b9d43c5606ebf1b27012aca333c7e2","unresolved":false,"context_lines":[{"line_number":387,"context_line":"----------------"},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"Current and new Ironic drivers will need rework to comply with the new"},{"line_number":390,"context_line":"state machine,"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"Implementation"},{"line_number":393,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_30f3b59f","line":390,"updated":"2014-12-09 17:42:30.000000000","message":"\u0027,\u0027 -\u003e \u0027.\u0027","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":114,"name":"Victor Lowther","email":"victor.lowther@gmail.com","username":"victor-lowther"},"change_message_id":"c2976a2ad61a7d698ccf4f7cfb8f3984be76d98c","unresolved":false,"context_lines":[{"line_number":387,"context_line":"----------------"},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"Current and new Ironic drivers will need rework to comply with the new"},{"line_number":390,"context_line":"state machine,"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"Implementation"},{"line_number":393,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_7019bd87","line":390,"in_reply_to":"3a961159_30f3b59f","updated":"2014-12-09 17:53:33.000000000","message":"Done","commit_id":"e5d5f59d9365ff51b61e780f9bccb5da4589f25c"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"c8b0761d048e84f3c0f0e432f5e62a8231f34c86","unresolved":false,"context_lines":[{"line_number":82,"context_line":"\"CURRENT-slash-slash-TARGET\" state."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Descriptions of the states for the current state machine can be found `here"},{"line_number":85,"context_line":"\u003chttps://github.com/openstack/ironic/blob/stable/icehouse/ironic/common/states.py\u003e`."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"New state machine::"},{"line_number":88,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"3a961159_56b75a86","line":85,"updated":"2014-12-09 18:16:03.000000000","message":"just noticed that this didn\u0027t render properly, there\u0027s no link under \u0027here\u0027.","commit_id":"e84effb5749f575e112d230404a403f49b177221"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"c8b0761d048e84f3c0f0e432f5e62a8231f34c86","unresolved":false,"context_lines":[{"line_number":431,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":432,"context_line":""},{"line_number":433,"context_line":"Anyone have a link to some developer session notes?  I was sorta busy"},{"line_number":434,"context_line":"being a whiteboard monkey:  https://i.imgur.com/tCxUCYk.jpg"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3a961159_5613da65","line":434,"updated":"2014-12-09 18:16:03.000000000","message":"I don\u0027t know if you want to change this or not. I\u0027m fine with it ;)","commit_id":"e84effb5749f575e112d230404a403f49b177221"}]}